by Sarbbottam Bandyopadhyay on Tuesday, 26 November 2013

+10
Vote on this proposal
Status: Confirmed
Section
Full talk

Technical level
Intermediate

Objective

Web is open platform, thus any application developed for this open platform should be accessible for any users, irrespective of their disabilities. Accessibility must be treated as the core feature of the user experience. Quite often, a web application that is keyboard accessible is considered to be accessible compliant. How ever which is partially true. For example, ‘hasgeek login’ form. There are visual indication of the error in the page, however for visually challenged user there is no indication for error and teh experience is more like an infinite loop. Using aria-invalid and aria-described by solves the problem.

Description

Every web site (e-commerce, forums, social networks etc) that deals with users uses web forms. Web forms are used in several scenarios, user registration, upgrade, profile update, posting an article, questions, comments. A plain old HTML form always serves the purpose, but quite an often, CSS and/or JavaScript are used to make the experience smooth and shiny. For example, password strength meter, form validations, custom drop-down menus, auto complete, modal dialogs etc. These shiny and dynamic stuffs look visually awesome and stunning.

Developers mainly focus on the 'look and feel' along with performance. Is the awesome looking UI accessible via keyboard completely, accessible for a visually challenged user?

If not, how to achieve it? How to make visually challenged users aware of all the dynamic changes/updates the UI is going through?
Many a times we use custom elements instead of native. For example, using a custom drop down menu instead of native select/options. It is quite easy to visually implement a custom drop down menus using div(s), ul(s) and li(s). But, is it completely accessible, via keyboard, by a user who is visually challenged?

This presentation will mainly focus on 'HOW' rather than 'WHAT' with respect to web accessibility and real life use cases of accessibility.

Speaker bio

Sarbbottam is a front-end engineer for Yahoo. He manages the UI for user registration flow. He is passionate about making the UI accessible for challenged user, cross browser compatibility of the UI and web performance. He firmly believes that any web application must always be functional without JavaScript and JavaScript must be used for progressive enhancement of the UI.

Comments

  • 3
    [-] Jitendra Vyas (@jitendravyas) 3 years ago

    +1 Glad to see a proposal on web Accessibility

  • 2
    [-] Kiran Jonnalagadda (@jace) 3 years ago

    Hey Sarbbottam, let me know what to do with the login page and I'll fix it right away. No need to wait to be embarrassed from stage. :)

    • 2
      [-] $ąяββ๏ţţąʍ (@sarbbottam) 3 years ago (edited 3 years ago)

      Hey Kiran,

      Please add required or aria-required='true' to the required elements.

      <input autofocus id="username" name="username" tabindex="1" type="text" value="">
      <input id="password" name="password" tabindex="2" type="password" value="">


      <input autofocus id="username" name="username" tabindex="1" type="text" value="" aria-required="true">
      <input id="password" name="password" tabindex="2" type="password" value="" aria-required="true">

      Should you want to use 'required' instead of 'aria-required', please make sure to use 'novalidate' attribute to the form to turn of default validation.

      Visually * indicate required but for a visually challenged person required or aria-required is required. Too many required in the last statement :).


      While displaying <p class="help-error"><span>This field is required.</span></p> in the DOM, please add aria-invalid='true' to the input elements.

      <input autofocus id="username" name="username" tabindex="1" type="text" value="" aria-required="true" aria-invalid="true">.

      Again visually the error message implies that there is error, to convey the same to assistive technology aria-invalid needs to be utilized.


      It will be great if "<span>This field is required.</span>" can be identified with a 'id' attribute and same can be referred in the 'aria-describedby' attribute to the input element.

      <input autofocus id="username" name="username" tabindex="1" type="text" value="" aria-required="true" aria-invalid="true" aria-describedby='#username-message'>.

      <span id="username-message>This field is required.</span>
      A nice speech bubble sort of UI creates the visual link between the element and message describing it. To achieve the same in assistive technology ‘aria-describedby’ is used.

      Hope it will be helpful.
      @sarbbottam

      • 1
        [-] Kiran Jonnalagadda (@jace) 3 years ago

        BTW, you appear to have two accounts. Let me know if you need help merging them.

        • 1
          [-] $ąяββ๏ţţąʍ (@sarbbottam) 3 years ago

          Oh, I thought they already got merged https://twitter.com/sarbbottam/status/405466905458130945.

          However, if it still appear to be multiple accounts, it will be great to merge both of them.

          • 1
            [-] Kiran Jonnalagadda (@jace) 3 years ago

            Funnel doesn't migrate data over to a merged account yet. I'll fix that. You might want to edit your name in the account settings though, as everything downstream up to the final schedule will read it from here.

      • 1
        [-] Kiran Jonnalagadda (@jace) 3 years ago

        Thanks! That is very helpful. Some of this will require changes to the underlying form library. I'll submit those patches upstream.

Login with Twitter or Google to leave a comment