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

http://www.w3.org/WAI/intro/wcag

I have found that even on the W3C sites there is a contradiction on this topic. For example the WCAG 2.0 H42 Technique uses an example (example 2) which shows using heading tags that are not properly nested. Under the resource links on that page there are two blog posts that indicate this as well, Pick a Heading and Quick tips for accessible headings. Yet if you look at the WCAG 2.0 G141 Technique it is clearly states that, “To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).”

I’d like to get your thoughts on this and how you think heading levels should be used…especially if you are a screen reader user and rely on the heading tags.

-Jeff

Flash accessibility is a common issue we come across.  Many people think that Section 508 and WCAG standards mean you cannot create a dynamic website…this I’m sorry is simply not true.  There is however a different learning curve needed to make Flash content accessible.  Here is a great post I found that discusses the accessibility/usability and some best practices for using Flash content… http://sixrevisions.com/usabilityaccessibility/adobe-flash-accessibility-best-practices-for-design/