Javascript Frameworks and Accessibility

[dacreativeguy]

I'm trying to find some definitive info on how javascript frameworks (specifically YUI) comply with Section 508. I've found vague references here and there in Google, but no 'smoking gun'. Anybody have links to pages that can answer my question?

 

[bootedbear]

I'm not particularly familiar with YUI, but I know that jQuery stresses the concept of "Unobtrusive JavaScript" where, in the same way that CSS should be used to keep style out of the markup, the behavior defined by JavaScript should be segregated from the structure of the HTML.

This makes it easier to author pages that "degrade" gracefully when JavaScript is disabled, and are friendlier to page readers and the like.

 

[angelwatt]

Like bootedbear eluded to, it's really how a developer implements a framework that really makes a web site accessible or not. A JavaScript framework cannot force a developer to use it in an unobtrusive way, or to make sure the page still works when JavaScript is disabled. This is why you're not finding anything, because no framework can guarantee accessibility. The vague finds you've come across are likely talking about how the framework works well to accomplish unobtrusive development, but again, they can't control what the developer codes up.

Edit: Here's a page at Wikipedia I found that has some decent info, especially the references at the bottom. Reference 14 links to a page for Dojo and talks about their approach to accessibility. Looks like a decent read for those interested.

Here's another helpful page that has a bunch of links related to AJAX accessibility.

 

[SrWebDeveloper]

ignore me

 

[SrWebDeveloper]

I code for the government and lecture about this subject often. Below are my thoughts on JS frameworks/Ajax taken from one of my 508 presentations:

Here is the actual requirement, verbatim, as per 1194.22 (Web-based intranet and internet information and applications) from the ammendment to the Rehabilitation Act of 1973 (29 U.S.C. 701) known as section 508:

12. 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

That is number 12, one of 16 total requirements actually, and after much research and consolidation of developer feedback including Internet discussion on how to best meet this requirement, I advise the following:

Best Practices:

Use the TITLE attribute if a text link:

<a href="javascript:myFunction();“ title=“Information about this link goes here…”>Start myFunction</a>

Use the ALT attribute if a link uses a graphic:

<a href="javascript:myFunction();"><img src=“image.gif” alt=“Information about this link goes here…”></a>

Use the <noscript> tag to include content for browsers with client side scripting disabled.

Use “onClick()” for basic link event handling as opposed to:

OnDblClick() – not supported by most screen readers or legacy browsers
OnMouseDown()/OnMouseUp()  - this is confusing to Assistive Technology devices
OnMouseOver()/OnMouseOut – i.e. image rollovers  - most legacy screen readers don’t support this, provide redundant text links
OnChange() – i.e. within select tags – avoid use entirely if possible
OnBlur()/OnFocus() – most screen readers don’t recognize this behavior, using this is ill-advised

If a script is used to generate popup menus or new windows, the web developer must also provide redundant text and/or links that match the text in the script.

In terms of AJAX, specifically:

As part of 508 compliancy for Federal Agencies with respect to web interfaces, the information provided by the script shall be “identified with functional text that can be read by assistive technology.”

The most common client software used as Assistive Technology includes:Screen readers such as text-to-speech screen readers such as JAWS and Window Eyes and screen magnifiers such as MAGic.

Modern web development more frequently uses AJAX (Asynchronous JavaScript and Extensible Markup Language), i.e. Dynamic HTML using write-in-place content updating to avoid screen refreshes, such as Netflix.com and Google Maps.

It is not clearly stated in any guidelines that AJAX applications are Section 508 incompatible
As of this writing, most Assistive Technology clients do not support AJAX extensions but this is improving as more companies release newer versions of their products into the market
Some feel “it depends on the implementation, just like any coding” but no standards are readily available to ensure compliancy – which puts the responsibility solely on the developer to “make it work”

Jim’s unofficial, informal but useful developer tips on how to “make it work”:

Include in a “Requirements Page” or disclaimer that JavaScript client side scripting must be enabled in the browser
Make use of the <noscript> tag block immediately following a <script> tag block.
Always provide an ALTERNATIVE means of accessing the same information either through <noscript> or as simple as a link to a non-AJAX page that performs the same function.
Always code to the AJAX/508 standard, not the Adaptive Technology (i.e. don’t code a specific solution for screen readers)

SUMMARY

This is what you need to know - best practices are suggestions, not guidelines! The burden is with the developer to code to W3C standards and not to the assistive technology versions or features. Use these suggestions to allow users with accessibility issues to attain your content without relying upon client side scripting. Provide alternatives using the suggestions or your own custom implementation, whichever works for you. Validation tools do not address presentational issues, merely syntax issues or missing elements or measurable metrics that will impair assistive technology devides.

Every developer with have a unique opinions - consider this a consolidation of techniques to help you get it done without too much extra work. By no means consider the information in this reply "the final say".

-jim