Bug 391824 - Accessibility improvements to Login page
Summary: Accessibility improvements to Login page
Status: RESOLVED FIXED
Alias: None
Product: Orion (Archived)
Classification: ECD
Component: Client (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 2.0 M2   Edit
Assignee: Mark Macdonald CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on: 391161
Blocks:
  Show dependency tree
 
Reported: 2012-10-12 15:27 EDT by Carolyn MacLeod CLA
Modified: 2013-01-14 12:46 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carolyn MacLeod CLA 2012-10-12 15:27:53 EDT
Notes:
- the user should be able to give keyboard focus to the twitter and news links
- the user should be able to give keyboard focus to the info area on on the bottom (why is this area a live region?)
- "more info" is not useful link text, particularly if there are multiple "more info" links

Use HTML5 section elements and ARIA landmarks to structure the page.
See these 2 diagrams for ideas:
  - page 9 of http://environmentsforhumans.com/2011/accessibility-summit/presentations/Kiss-a11ysummit-screenreaders.pdf
  - page 42, 43 of http://www.slideshare.net/webaxe/how-build-accessible-web-app-a11ybos
See this step-by-step process for defining the page's logical structure:
Section 3.2.7.1 in http://www.w3.org/WAI/PF/aria-practices/#kbd_layout

Some possibilities for the login page:
<header role="banner"> for the orion logo
<nav role="navigation"> for the twitter and news links
<div id="login-window" role="main"> for the "login-window" main div
	(maybe? or maybe the orion-landing-area is the "main" area?)
<div id="orionLogin" role="form"> for the login form
<aside id="orionInfoArea" role="complementary"> for the info area
Comment 1 Mark Macdonald CLA 2012-10-12 16:34:02 EDT
I would like to be able to cancel the "Log in" and "Create an account" forms with the ESC key. Currently, you have to focus the Cancel button to do this.
Comment 2 Carolyn MacLeod CLA 2012-10-30 02:43:11 EDT
For the <input> with id="login" and title="Username", the autofocus="true" attribute has the wrong value. It should be autofocus="autofocus" (believe it or not). See http://www.w3schools.com/html5/att_input_autofocus.asp

Also, on that same element, I am not sure what autocapitalize="off" means. It does not seem to be an attribute of <input>.
See http://www.w3schools.com/tags/tag_input.asp
Comment 3 Carolyn MacLeod CLA 2012-10-30 03:23:37 EDT
For the element with id="myopenidLogin", the alt="myOpenID" isn't very useful. Alt text should be meaningful if the images aren't there (or can't be seen). Perhaps it should be the same text as the title attribute (i.e. "sign in with existing Orion account"). 

Actually, the other 2 alt texts ("Google" and "Mozilla Persona") would probably be more useful if they were the same as the title also ("sign in with associated Google account" and "sign in with associated Mozilla Persona account").

Please see this w3 recommendation for providing useful alt text: 
http://www.w3.org/wiki/HTML/Elements/img#Requirements_for_providing_text_to_act_as_an_alternative_for_images

Please also consider the following 2 points when adding title (i.e. hover) attributes to elements instead of visible text (i.e. innerHTML):
1) the title attribute does not show up anywhere on a mobile browser (so users who have never seen the Persona logo, for example, can't just hover over the icon on a tablet to figure out what that icon is).
2) the title attribute does not show up if you use the keyboard to tab to an element (i.e. sighted keyboard-only users can't hover over icons either).

I don't have a nice solution to the hidden title hover problem - it seems to be something that the browsers should figure out someday. <g> I am only mentioning it so that it can be kept in mind for future development. (Note that if we ever do provide innerHTML for these elements, then we do need to delete the redundant title attributes).

(Note also that screen reader users are not affected by this "hidden title hover problem" because screen readers use the alt text).
Comment 4 Carolyn MacLeod CLA 2012-10-30 03:38:27 EDT
With Firefox 16.0.1 and JAWS 14.0.918 the screen reader gets a bit confused when tabbing through the sign-in links. It does not recognize the Orion sign-in link (it reads "Have an account? Sign in:" instead of "sign in with existing Orion account" or even "myOpenID"). 

These <div>'s should have a role. Probably role="link". Are they "links" for sure? Or are they "buttons"? Please compare these 2 aria design patterns:
http://www.w3.org/WAI/PF/aria-practices/#button
http://www.w3.org/WAI/PF/aria-practices/#link
Comment 5 Carolyn MacLeod CLA 2012-10-30 04:07:20 EDT
re: comment 4
Actually, I guess these are already links (specifically, a link with a div with a div), so maybe role="link" on the inner div would be redundant.

<a tabindex="-1" ...> 
   <div tabindex="-1" class="openIdWrapper">
      <div title="sign in with existing Orion account" tabindex="0" ...></div> 
   </div>
</a>

Can we remove a layer somehow? Maybe the openIdWrapper div? (by the way, a div does not need tabindex="-1" because by default it does not take focus).
Comment 6 Mark Macdonald CLA 2013-01-11 14:47:15 EST
- Semantic elements (nav, aside) are used for the info area and banner
- The various forms now have role="form" and area-labelledby pointing to their header
- Appropriate roles have been added for stuff in the top banner
- Twitter and Orion News can be tabbed to
- title and alt attributes fixed
- ESC can be used to cancel out of a form
- the Orion/Google/Persona login buttons are now role="button", inner <div> is gone

* http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=b08de4ac0ad024a2a9e4c02df0e469c014c439b7
* http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=250309a6f8902ced5b89f8a26abb0133106e8290
Comment 7 Carolyn MacLeod CLA 2013-01-14 12:46:55 EST
Thanks, Mark! Fixing up the focus problems and adding roles made the page much more accessible. I was able to notice a few other items that I will open new bugs for. Much appreciated!