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 Access Board has just released the draft of the refresh for the Section 508 standards. You can view them at this link: http://access-board.gov/sec508/refresh/draft-rule.htm

I first became aware of the new version of this editor from the following news article: FCKEditor drops the F. This article mentioned that the editor was now ‘fully’ accessible to screen readers and keyboard only users. Even the main page for the CKeditor website (http://ckeditor.com/) makes the claim that it has full accessibility support.

This editor is open source and versatile when it comes to implementation so it is has a large install base. You may have used this editor yourself without even knowing it. With the growing attention to accessibility and the legal requirements around this topic an updated ‘accessible’ version of this editor is very timely.

I have done some testing in the past with the FCKEditor in regards to accessibility and was curious if this new version was really accessible. So I took a ‘quick’ peek to see for myself. My focus for this quick test was not if the editor created accessible content, but on if the editor itself was accessible.

Keyboard Only

I was pleasantly surprised to find that the CKEditor does in fact support the use of only a keyboard! Many of the past keyboard problems with the FCKEditor have been fix. I honestly did not expect the level of keyboard support that I found in the new version of this editor.

To say the least I was very pleased! The one drawback was finding the reference to the keyboard only commands. It wasn’t that hard to find but did take me a few minutes. What would be nice is to have a link or easily discoverable way to allow a user to get this information from within the editor itself.

You can find the reference for the most common supported keyboard commands and navigation shortcuts in the CKEditor Accessibility topics document.

Screen Reader

When it came to using a screen reader like JAWS with the CKEditor I was sure I would discover some major issues. Again, to my surprise JAWS and the CKEditor worked fairly well together. There is still a steep learning curve and at times JAWS got lost which required some screen refreshing and rediscovering of current focus to get my bearings. Compared to the way JAWS and the FCKEditor worked (or should I say did not work) together in the past this was a tremendous improvement.

To CKEditor’s credit most issues of using JAWS with this product are documented. This was in the CKEditor’s Accessibility document mentioned early or if you prefer jump directly to the JAWS section of that document here.

In case you are interested I used IE 7.0.6001.18000 and JAWS 10.0.1142 for my testing.

In Summary

There are still some areas that are problematic such as switching from WYSIWYG view to the Source view. When this switch occurs the focus jumps from the editor to the top of the page. This is not good for a screen reader user, screen magnifier user or a keyboard only user.

Also, I was not able to find a complete list of keyboard commands for ALL available tool bar options. It could be that those have been deprecated. The FCKEditor had a much larger list than that outlined in the current CKEditor Accessibility Document.

In all fairness I did not do an exhaustive search but I still feel a reference like that, if still applicable,   should be easily discoverable and even be referenced within the CKEditor Accessibility Document.

I should also mention that I did not do a complete test of the editor for accessibility but took a high level approach. Even so, that high level approach shows that the creators of CKEditor have put great effort in making this an accessible product.

This is very commendable because all too often the minimal effort is done so a product can be called accessible. I am not saying that the CKEditor does not have accessibility issues but compared to the previous versions of the FCKEditor the difference is night and day! This was a *real* effort to create an accessible product and so I offer a hearty ‘WOOT!’ to the CKEditor team!

If you have had a similar or different experience with the new CKEditor please post your comment here.

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/

I thought maybe it was a good time to put up a few posts that just lay out some basic information for some of the different sets of criteria that is out there.  Here I’ll focus on Section 508 and the 1194.22 guidelines that at the very least can be a quick resource for what they are.

A very quick history of Section 508:  The Rehabilitation Act was amended in 1998 and requires Federal agencies to make sure their electronic and information technology accessible.  While that sounds simple enough we can quickly complicate it with the separation of software, telecommunications, web content, etc… so for now let me just provide a simple list of the web content guidelines also known as 1194.22. 

§ 1194.22 Web-based intranet and internet information and applications.

(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

***These can also be found at http://www.section508.gov, but don’t go there looking for too much help as unfortunately the criteria is provided but no real interpretation or example is.***

I hope this helps at least from a simple perspective of what the requirements are, if you have specific questions feel free to sign up, log in and ask away as we’ll do our best to help you out.