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.

Update 9

What I’ve done:

  • Updated Design document can be viewed here 
  • Written a detailed overview post of work done

What I’ll be doing:

  • Continue writing the detailed overview post
  • Write another post on things tried that failed, recommendations, and future work

Problems:

None

 

 

Update 8

What I’ve done:

Completed adding the first iteration of WAI-ARIA to the Orion site.

What I’ll be doing:

See problems.

I will also be updating my Design document, and writing up a summary.

Problems:

My fixes don’t work on Windows, but they do on Mac. According to Carolyn, I will have to research ARIA live regions more so that when the text is a div-tag is changed, the live region is spoken. The issue might be that the div-tag has style=”visibility: hidden;”  and then set to style=”” in order to show the error.

Update 6 / 7

What I’ve done:

Continuing the same procedure from week 5, no problems so far. Some useful resources that have helped me add ARIA are:

ARIA-live regions

Directing screen reader focus

Adding semantic context to mark up

What I’ll be doing:

Research how to get WAI-ARIA to read out items in a predefined order. If this takes too long, I’ll have to leave it aside and focus on polishing up the website.

Problems:

None

Update 5

What I’ve done:

I’ve added ARIA to the Navigator page and the Sites page on Orion. There is a lot of testing involved as I have to go through many use cases and see if the website will still perform well. There is also a lot of time spent figuring out the right combination of attributes to use to increase the semantic context for the screen reader, and to enable the right text to be read by it. More details of this will be in the project design document.

What I’ll be doing:

I’ll be continuing to add ARIA to the rest of the website. Ideally the Repositories page, but also the Sites page too.

Problems:

I am waiting on Ken to get back to me on merging my changes with the Orion codebase. I’ve kept a backup copy on my github page.

I’m also have trouble trying to control the order things are detected by the Screenreader. I’ve been doing a lot of searching online to see if I can find a solution for this. So far no luck, but I have sought out advice from Carolyn.

Update 4

What I’ve done:

I’ve added ARIA to the homepage login process. So now the screenreader will be able to detect:

  • if a wrong password is entered
  • forgotten password link
  • create new user link

What I’ll be doing:

I’ll be continue to add ARIA to the rest of the website, as the screenreader can skip important features of the website. Another issue is the that ordering of things being read is not logical. I want to see if I can control the flow of items being read so as to illustrate the structure of the website better.

Problems:

I’ve been editing Orion within Orion itself. When I create a git branch, do my chances, and try to send a pull request, it merges my changes with changes from the past as well. However, if I do this the “regular” way (i.e. through terminal), it works just fine. I’ve contacted Ken and Carolyn about this. Ken says he will look into the issue and will also fix the wiki so as to make the process clearer.

Update 3

What I’ve done:

I made a list of accessibility issues on the Orion hub. These issues can be found in this document:

https://docs.google.com/document/d/1Vkm_JMkl7tH0otyOfzT09I4b1vmI9CFDZN3R1-g0gt8/edit?usp=sharing

I created a subset of them on Bugzilla and have started on working to fix them.

What I’ll be doing:

I’ll be getting familiar with the codebase and I’ll learn how to self-host the Orion project so that I can test the changes made locally. I’ll continue to fix the bugs, with the guidance of Carolyn and Ken.

Problems:
None