Final Update: Details

(updated Apr 15)

1. Warnings on sign up page are not read out.
Warnings are displayed dynamically. In order for the screen reader to capture this change in the DOM, I added the aria-live and tabindex attributes to the div.

<div id="errorMessage" aria-live="assertive" tabindex="0">
Invalid user or password
</div>

In the code above, tabindex=”0″ allows the div to receive focus from the screen reader. Also, when the text inside the div is changed, aria-live=”assertive” lets the screen reader become aware of the text change and will read it aloud.

When I tried this out, the results I received were not what I expected. Using WAVE to test the changes, it showed that WAI-ARIA was not present for the warnings section. This is a good sign.

Screen Shot 2013-04-04 at 11.08.57 PM

However there was a strange bug when testing with VoiceOver. The screen reader would read all the elements on the Orion page except for the warning, and then on the second time around, it would pick up the warning. This is not useful for the user; the screen reader should pick up the warning on the first “time around” the page. I had trouble figuring out how to specify the ordering for aria-live regions. I tried adjusting the tabindex for other elements, and adding aria-live attributes to parent divs to try and catch the screen readers attention. None of these combinations worked when I tested it with VoiceOver. After a lot of trial and error, I realized that by moving the placement of the warning-div, I was able to accomplish this. Originally, in the HTML document, the warning-div was placed before the login-form. Therefore, when the warning-div appears on the page, it was not detected by the screen reader since it reads in the order of things in the HTML document (and at that point, it had already passed it). This is why the screen reader would detect the warning on the second time around the page. So, by moving the warning-div to come after the login-form, the screen reader was able to read it at the right time (i.e. after errors in the login-form are detected).

2. Screen reader does not see “Forgot Password?” link
This is an important link that is not picked up by the screen reader. To gain focus from the screen reader, I added the tabindex attribute which fixed the bug.

<div><a id="resetUserLink" tabindex="0"></a></div>

Using WAVE to test the changes, it showed that WAI-ARIA was no present for the link, and it was read by the VoiceOver.

Screen Shot 2013-04-04 at 11.08.35 PM

3. No WAI-ARIA present for username and password field 
WAI-ARIA is used to enrich accessibility on the internet. This was lacking in the form fields, so I added aria-required and aria-invalid. These attributes allow the screen reader to have more semantic context, and by extension the user.

<input type="text" name="login" id="login" placeholder="username" title="Username" autocomplete="on" autofocus="autofocus" spellcheck="false" aria-required="true" aria-invalid="true">

Using WAVE to test the changes, it showed that WAI-ARIA was now present for those form fields.
Screen Shot 2013-04-04 at 11.01.32 PMScreen Shot 2013-04-05 at 12.00.05 AM

4. ARIA labels missing on Reset Orion Account form
A semantic presence was missing from the Reset Orion Account form. Also, a label was missing for the form fields which is problematic for screen readers. To fix this, I’ve included the name, title, and aria-label attributes.

<div>
  <input type="text" id="reset" placeholder="username" name="username" title="username" aria-label="username">
</div>
<div>
  <input type="text" id="resetEmail" placeholder="email" name="resetEmail" title="resetEmail" aria-label="email address">
</div>

To check my changes, I used WAVE. The results showed me that this form has been fixed to incorporate semantic features for screen readers. Screen Shot 2013-04-04 at 11.37.30 PM

5. Orphaned labels on Sites page
There is some accessibility work required for the table on the Sites page. When tabbing through this section, users that do not require screen readers and can see are able to visually make the link between labels and their corresponding values. However, for users that require a screen reader, this link is not clear. Sometimes forms can be poorly marked-up or organized.

Screen Shot 2013-04-05 at 1.57.16 AM

There needs to be a way to link the label with its value in the HTML document. This can be done by adding for="<id>", where <id> is the ID of the associated element that the label is for.

<tr>
   <td>
      <label for="site-editor_name"></label>
   </td>
   <td>
      <input id="site-editor_name" value="orion" pattern="\s*\S+\s*" required="required"></input>
   </td>
</tr>
<tr>
   <td>
      <label for="site-editor_hostHint"></label>
   </td>
   <td>
       <input id="site-editor_hostHint" value="localhost" pattern="^(?:\s*|[A-Za-z0-9-_]+)$" required="required"></input>
   </td>
</tr>

Testing the changes with WAVE shows that this change correct makes the link.

Screen Shot 2013-04-05 at 2.57.45 AM

Unsolved Issues for Future Work
There does not seem to be a [cross-platform] solution yet to get aria-live to work for hidden divs.

After talking to Carolyn, she has proposed a work-around to the problem that works for Windows:

– LoginWindow.html:

<div id="errorWin" style="visibility: hidden;" aria-hidden="true">
   <div id="errorMessage" role="alert" aria-atomic="true" aria-live="assertive">&nbsp;</div>
</div>

– LoginWindow.js:

        function showErrorMessage(msg) { 
                if (typeof msg !== "undefined") { 
                        document.getElementById("errorMessage").textContent = msg; 
                } 
                var errorWin = document.getElementById("errorWin"); 
                errorWin.style.visibility = ''; 
                errorWin.setAttribute("aria-hidden", false); 
        } 

        function hideErrorMessage() { 
                document.getElementById("errorMessage").textContent = "\u00a0"; 
                var errorWin = document.getElementById("errorWin"); 
                errorWin.style.visibility = 'hidden'; 
                errorWin.setAttribute("aria-hidden", true); 
        }

Unforunately, this does not work on a Mac. This change actually isn’t picked up by the screenreader, so it doesn’t read out the warning when shown. My original solution requires the user to tab in order for the screenreader to pick up the alert. An ideal solution would read the alert immediately (i.e. when the user clicks the Sign In button).

Although aria-live is still evolving, the general consensus for using aria-live for hidden divs is:

  • use aria-hidden: http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden. This allows screenreaders to properly skip elements where aria-hidden=”true”. 
  • also combine this with CSS (visibility=”hidden”)
  • and role=”alert” which will fire an alert to the screen reader when the it becomes visible (aria-hidden=”false”, visibility=”true”)

Again, this does not work for all platforms, but is good to know and an appropriate place to start researching from.

Summary
Overall, there is now an increase in the semantic presence and logical structure with the addition of ARIA attributes. Below is a summary of the results from WAVE.

ARIA present for all account types

ARIA present for all account types

ARIA present for all elements of Create An Account form

ARIA present for all elements of Log In form

ARIA present for all elements of Reset Orion Account form

ARIA present for warnings on landing page

Adding logic and semantics to labels with associated fields.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s