Mike specifically asked about the Section 508 requirement 1194.21(c) “A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.”

Mike wanted to apply this subpart to a log in page where he felt that focus should be forced to one of the input controls for the log in information. His colleague was arguing that it was not necessary to do this to conform to the Section 508 requirements.

What do you think? I have included my answer to Mike Jr below for your review as it contains (in my opinion) a lot of food for thought.

[Start of my reply to Mike Jr]
Hi Mike Jr,

First off 1194.21 is the subpart of Section 508 that is dealing with Software Applications and Operating Systems. So “technically” it would not apply to Web-based intranet and Internet information and applications that are only HTML based.

That being said, the common approach today is to apply the Section 508 requirements across the board to whatever you are evaluating for conformance. This is because Section 508 is outdated, so for those standards to be beneficial in today’s world the blanket approach of applying to them to everything, regardless of category, is often employed.

As the Section 508 refresh in the process of being adopted it appears that Section 508 will most likely use, or closely follow, the WCAG 2.0 Level A, AA guidelines. So if you are looking to conform with the future refreshed requirements as well, shoot for the level AA guidelines of WCAG 2.0.

In answer your question about 1194.21 (c), that requirement is focusing on ensuring that the current focus is visible to the eye as well as visible to an assistive technology. So you must be able to discern where the current focus is visually as well as programmatically. This is true even if you are only applying this requirement to a web page, as you stated is the case.

In your example of a log in page loaded in a browser window it is not necessary to set the focus to one of the input controls on page load (initially opened) for conformance to Section 508, as long as the user can tab to those controls and visually discern the current focus and as long as that focus is also identifiable programmatically for the AT software. It doesn’t hurt to add that type of functionality as it does improve usability for everyone, but it not required for accessibility. See the guide to “Guide to the Standards” for Section 508, 1194.21 (c) at this link: http://www.access-board.gov/sec508/guide/1194.21.htm#(c))

Additionally you can refer to the WCAG 2.0 level AA 2.4.7 guideline on understanding making focus visible. That link is: http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html.

To be clear, if we were talking about a software application window and not an Internet browser window then making sure a control had default focus when that application window is loaded would be necessary. You will notice that in a browser window if the web content does not have focus by default at least the one control that is part of the browser does have focus. I do not think this detail is actually covered under any of the accessibility guidelines but my guess is that it is outlined somewhere in the accepted standards for application/software, but I could not tell you where.

Anyway, kudos to you for wanting to improve the overall user experience along with your efforts for accessible access! Too many times developers only want to do the bare minimum to get the code ‘out the door’. A good user experience is important and ensuring that your content is designed for accessibility only helps to improve that user experience. Keep up the good fight!

[End of my reply to Mike Jr]

Mike Jr’s orginal question can be found here: http://stackoverflow.com/q/9896700/1301573

The fact that IE works is actually an old IE bug and some dumb luck.  You’ll notice in IE that if there is only a title attribute it will be read by JAWS, if there is a title attribute and alt-text the alt-text is read by JAWS.

2.  JAWS defaults to read alt and not Title attributes however this can be modified through the configuration manager…Set Options–>HTML Options–>Links–>Use Title; this will change your settings until you change them back which I don’t recommend but it is a good way to show that your code is working in this manner.

The real fix here would be to add alt-text which should be picked up by default with JAWS 10 in Firefox.

Just as another possibility you can do an about:config in Firefox and make sure browser.chrome.toolbar_tips is set to true or you won’t see the tool tips at all.

Long story short here is that we’ve all gotten so used to something not working right that we came to think of the behaviour as being correct.  Bad on us.