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

I recently came across a tool I hadn’t used before and wanted to share it and another resource for analyzing color contrasts. If we look at 1.4.3 within WCAG 2.0 it lays out the groundwork but having a tool to use is such a nice resource to have.

Per the W3C:

“1.4.3 Contrast (Minimum):The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

•Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

•Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

•Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.”

Additional contrast items are addressed in 1.4.6:

“1.4.6 Contrast (Enhanced):The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA)

?Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;

?Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

?Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.”

(http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast)

There are two free tools I’m listing for use though surely there are more available:

1. Luminosity Colour Contrast Ratio Analyzer-Juicy Studios

This seems like a very usable resource and operates directly from the website of Juicy Studios. I’m impressed at the simplicity of it and appreciate the efforts to make it not just a tool for usability and accessibility but accessible in itself. http://juicystudio.com/services/luminositycontrastratio.php#specify

2. Contrast Analyser -The Paciello Group

I’ve used this many times and you get a simple interface that allows you to enter the html for your colors or switch modes and use a mouse pointer to select given colors that are currently on your screen. This is a nice touch when actively looking at a page. It does however require you to download it and run it from your desktop. http://www.paciellogroup.com/resources/contrast-analyser.html

Depending on your needs I’d expect either of these will work well for you and encourage you to meet the guidelines for easier use by all.

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

Today I sat in on the the “Assistive Technology Access to Flash and PDF” session presented by Matt May from Adobe Systems.

There it was announced that the next release of Acrobat, Acrobat Reader, Flash Player and Flex will support the iAccessible2 API. MSAA is what these products currently use which limits the accessible API to Windows platforms. This is great news as this will expand accessibility for these products beyond the Windows platform and allow users of OS2 and Linux to make use of the accessibility features in these products.

If you are not sure what iAccessible2 is, Peter Korn’s Weblog has a great explanation at: http://blogs.sun.com/korn/entry/completing_the_accessibility_picture_iaccessible2.

In addition to the support of iAccessible2, Adobe is planning on including support for the ARIA specifications in the near future for Flash Player and Flex. This will make it easier for developers to expose Flash content to assistive technologies.

It sure is nice to see advancements like this being made in these products. The hope is that the industry as a whole will follow Adobe’s example!

If you happen to be at this conference, feel free to stop by the HiSoftware booth #108 and say ‘hello’ as that is where I’ll be hanging out!

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.

Download Inspect32 from here.

Watch Video Tutorial Full Screen.

For those of you who might not know what it is, ColdFusion is used on web application servers to do much of the magic that we associate with Internet web pages.  It’s used for querying databases and creating content that then magically shows up on your browser when you go to Amazon to buy a book or Alaska Airlines to book a flight.  CF is kinda like PHP or Active Server Pages.  The neat thing for techno dummies like me is that CF is super-easy to use.

In fact, potentially too easy… which gets me to New Accessibility Thought Number One: “Accessibility Might Get Harder as Tools Get Easier.”  In CF, it’s ridiculously easy to do things that would otherwise be really hard.  Use a <CFCHART> tag and your data gets magically transformed into a JPEG, use a <CFDOCUMENT> tag and your printer-ugly HTML suddenly becomes a beautifully formatted Acrobat file that you can e-mail to your client.  Sure, there are a million and one attributes that each tag can take– and these all affect some little part of what comes out– but I ultimately have no idea how this stuff works.  Worse yet, I have no idea how it will work with the different AT’s out there.  Now don’t get me wrong: I think Macromedia (and now Adobe) are industry leaders in accessibility.  But, from working on the “other side” of accessibility for so long, I also know that solutions are often a matter of rolling up your sleeves and playing with the code and seeing how a screen reader hits it.  Now, when I hit View | Source  in IE and see what CF created, my head spins looking at the code that I have no control over (if you don’t believe me, try an innocent-looking <CFTREE> control in your CF template and see what shows up).  Then again, my dad has the same complaint about his new Toyota and not being able to fix it like his good ole Ford.

At the same time, my recent foray to the other side of the techie world has me babbling heretical New Accessibility Thought Number Two:“Retrofitting Ain’t That Bad.”  When you create a new building and forget to put in a ramp, retrofitting means calling out the jack hammers and making some really costly repairs.  In most HTML and CSS, it isn’t that bad provided that the design isn’t that dynamic to start.  The techniques are well-understood.  Here comes the real heresy, however– in the mock-up and brainstorming phase, accessibility sometimes gets in the way.  Why put an alt attribute on an image if I’m still so early in the design phase that I’m not even sure I’m going to keep the image at all?  Why put headers and id attributes in table cell tags when I’m not even sure how many columns and rows the table is ultimately going to have?  I can’t believe that even the most die-hard, accessibility-oriented web developers out there make their rough drafts fully accessible– and it’s precisely because they know that retrofitting some things are just going to be really easy later on.