2

"1194.21 Software applications and operating systems" has this to say about focus: "(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."

A colleague is arguing that the above rule does not require that a selected window have a current focus when it is initially opened. Only that when a window has a current focus, that current focus must be well defined and that the focus move as the user navigates among the interactive elements (e.g. tab).

Is the above rule assuming that every window will have a current focus when it is opened? Or is a current focus not required?

I think that it would be a poor user experience for someone using assistive technologies to have to search in vain for the element that has focus when a new window opens. Or am I overlooking something?

Mike Jr
  • 1,789
  • 3
  • 14
  • 21
  • I mean a web window. In particular, a login page. The as-built login page does not have focus and a user would have to press tab many times to get focus (and the carrot) into the username text entry box. – Mike Jr Mar 27 '12 at 20:00
  • Concerning having to press tab many times, it is [advised](http://www.access-board.gov/sec508/guide/1194.22.htm#%28o%29) to place a "skip" link to get to the page's main content when this is the case. The skip link can be styled to be off-screen since it is targeted at screen readers. We [use](http://www.nhi.fhwa.dot.gov/) the following style.`#skiplink { height: 1px; left: -10000px; overflow: hidden; position: absolute; top: auto; width: 1px; }`This would of course be moot if you are immediately moving the focus down the page. – weir May 23 '12 at 15:21

1 Answers1

3

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!

-JeffS

Jeff Singleton
  • 46
  • 1
  • JeffS, thank you for your full and thoughtful answer. I will submit a change request to have focus set in the username text entry box. If no focus is compliant then it can't be a problem report. – Mike Jr Apr 03 '12 at 19:56
  • Hi Mike, one thing you should be aware of is that if you are dealing with a Section 508 review from one of the Federal groups and they are saying you need to set focus this way then you probably should add that functionality. Since 508 is so vague and open to interpretation it gives those groups the ability to call out non-conformance issues in areas that they do not really apply. These groups are not being malicious, although at times it may seem that way, but rather are trying to ensure accessibility for all. So you just have to cater to them the best you can. – Jeff Singleton Apr 04 '12 at 17:05