Hans Hillen from TPG is presenting a Flex Accessibility Webinar in conjunction with Adobe. It will be on Wednesday, July 21st 12:00 noon, US EST, and it’s free to attend.

Webinar details

• Flex Accessibility Webinar.
• Wednesday, July 21 12:00 noon US EST.
• Captions will be available.

Attendance details

The meeting room address is https://admin.adobe.acrobat.com/_a227210/a11y

Login as a guest, no password is required.

Any questions, contact us at info@paciellogroup.com or call us on +1 603-882-4122.

Supported Screen Readers

The latest versions of these screen readers have partial support for Chrome now:

• System Access to Go (Windows)
• VoiceOver (Mac OS X)

These screen readers do not yet recognize Chrome’s non-focusable web content (links, form fields and other focusable content is spoken as expected), so you will be unable to enter “browse mode”:

• JAWS (Windows)
• Window-Eyes (Windows)
• NVDA (Windows)

We hope to work with all screen reader developers to resolve any issues so that they can enable full support for Chrome.

The list above is not a comprehensive list of all screen readers, but in the interest of prioritizing support for the greatest number of users, we believe that supporting the screen readers above will have the greatest impact. If external developers are interested in helping to add support for additional screen readers, we would welcome the help. 

For more detailed information about the technical design and current status, see the Accessibility Design Document.

AViewer Features

For those who have used inspect32 the way the viewer works should not be overly unfamiliar. At the top of the viewer window there is a toolbar consisting of the following buttons:

The AViewer Toolbar

1. Watch Focus (F4) - Information will be displayed for the element that has focus
2. Watch Cursor (F5) - Information will be displayed for the element that is under the cursor
3. Show Highlight Rectangle (F6) - places a visible highlight rectangle around the element that is currently being inspected
4. Copy Text to Clipboard (F7) - copies all the information currently displayed to the clipboard
5. Focus Rectangle Only (F8) - disables all features except the keyboard focus rectangle
6. Navigate to Parent Object (F9)
7. Navigate to First Child Object (F10)
8. Navigate to Previous Sibling Object (F11)
9. Navigate to Next Sibling Object (F12)
10. Show Online Help (F1) - opens the Aviewer help in a browser window.
11. Show Font Dialog (F2) - Font dialog for adjusting the font/font size of the text in the Aviewer interface.
12. Desktop Mode - Disables HTML and ARIA  inspection features.
13. Register Ia2 Menu - In order to inspect IAccessible 2 information the DLL needs to be registered on initial use.
    1. Register
    2. Unregister

Below the toolbar are the Select Display checkboxes:

Select Display

1. MSAA - When checked MSAA information is displayed in the listview.
2. ARIA - When checked ARIA information is displayed in the listview.
3. HTML - When checked HTML information is displayed in the listview.
4. IA2 - When checked IA2 information is displayed in the listview.

Below the Select Display checkboxes is the information listview and the code display text arera.

Installing the AViewer

1. Download the AViewer zip file (461 kb)
2. Unzip.
3. Start the AViewer.exe.
4. Remember to register the IA2 DLL first time you start the AViewer.

Notes:

• Runs on Windows only.
• The full range of inspection features can be used on web pages in Firefox and Internet Explorer. Note: IE does not support the IA2 accessibility API.
• Web pages in other browsers can be inspected in desktop mode only. Note: Most do not expose much information via accessibility APIs.
• Feedback on the functionality welcome!
• Feedback on the accessibility of AViewer welcome!
• To provide feedback and report bugs email Steve Faulkner sfaulkner@paciellogroup.com
• Many thanks to JUn for his work on the AViewer.
• And yes it is HTML5 ready!

Terms of Use Notice:

The AViewer beta software  is Freeware.

By accessing or using the AViewer, you acknowledge that you have read, understood and agree to be bound by the AViewer Terms of Use.

You may use the AViewer Software (the “Software”) for your personal use to help you determine the accessibility of your web content. For commercial use of this software contact Brian Landrigan blandrigan@paciellogroup.com.

THIS SOFTWARE IS BEING PROVIDED “AS IS”, WITHOUT ANY EXPRESS OR IMPLIED WARRANTY. IN PARTICULAR, THE PACIELLO GROUP (TPG) DOES NOT MAKE ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE RELIABILITY, QUALITY, OR MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. ADDITIONALLY, TPG DOES NOT GUARANTEE THAT USE OF THIS SOFTWAREWILL ENSURE THE ACCESSIBILITY OF YOUR WEB CONTENT OR THAT YOUR WEB CONTENT WILL COMPLY WITH ANY SPECIFIC WEB ACCESSIBILITY STANDARD.

The Google Chrome Screen Reader Accessibility Petition

To:  Google, Inc.

We, as screen reader users, feel that Google’s new and innovative Web browser, Google Chrome, still has a long way to go in accessibility. We are just asking for the developers of this flourishing browser to consider the needs of a growing audience who is interested in using this browser. We should have the choice to use this browser, and should not be shut out because of conditions we cannot control.

Web page text is not readable, and nothing is spoken with various screen access programs such as JAWS, Window-eyes, NVDA, and others. Also, the menus need help in order to be accessible to most windows screen readers.

On Linux, the situation is worse. Orca, the GNOME based screen reader, cannot even access this application due to the way the interface is written.

In 2010, having inaccessible applications is simply appalling and a Web browser coming from a great company such as google should not be subjected to that horrible label of ‘inaccessible’. Inaccessible programs translates to blind and visually impaired individuals being shut out from using this application. That is not acceptable.

Sincerely,

The Undersigned

Sign the petition

If you feel that Google has not made the accessibility of Google Chrome a priority, have your say - Sign the petition. Maybe they will listen.

Further Reading

• Google Chrome Accessibility - design documentation 
• Freedom of Choice
• Google Chrome 2.0 Accessibility Improvements?
• Google Chrome Accessibility
• Google Chrome Frame - accessibility black hole

The HTML5: Techniques for providing useful text alternatives document is intended as a replacement for the text alternative examples and authoring conformance requirements in section 4.8.1.1 Requirements for providing text to act as an alternative for images, of the current editors draft of the W3C HTML5 specification.

Aims of HTML5: Techniques for providing useful text alternatives:

• Provide clear and practical advice on how to  provide appropriate text alternatives for images using currently supported  techniques.
• How to make use of the new features available in HTML5 and WAI-ARIA for providing text alternatives.
• Understanding the advantages and disadvantages of each technique in reference to browser and assistive technology support.
• Provide normative rules for each technique in regards to whether its correct use results in a conforming HTML5 document.
• Harmonization of HTML5 document conformance with WCAG 2.0 in regards to image text alternatives.

How to get involved

If you want to comment or contribute on the HTML5: Techniques for providing useful text alternatives draft you can file a bug or email: faulkner.steve@gmail.com or email a comment to public-html-comments@w3.org.

To get involved further you can join the W3C HTML Working Group.

For example, the JAWS screen reader provides frame navigation keys: M and Shift+M to cycle forward and back through frame and iframe elements. JAWS also provides a frames dialog (open using insert + F9 that displays a list of frames and iframes on a page identified by their titles. If the title attribute is not present on the frame/iframe then the URL of the source document for the frame is listed.

Furthermore, when a page loads users of some assistive technology  hear information about the content of the page including how many frames are present. So understandably informing users of frames that have no usable content and providng access to them is a sub-optimal outcome.

How to ensure an iframe is hidden

If an iframe contains content that is not intended for users, there are a number of things you can do to ensure it is not available to any users:

1. Use CSS display:none
2. Set the height and width attributes to “0″
3. set the tabindex attribute to “-1″
4. And just in case a user still manages to encounter the iframe, set the title attribute with text indicating it does  not contain anything.

Code example:

CSS:

iframe.hidden
{
display:none
}

HTML:

<iframe src="javascript.html" width="0" height="0" tabindex="-1" title="empty" class="hidden">

The Future - the hidden attribute

HTML5 includes a hidden attribute that can be added to any element:

When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.

When supported, the use of this attribute will make the hiding of elements and element content, such as an iframe, simpler.  Unfortunately at this time no browser supports the hidden attribute, so taking into account legacy software it will be some years before the use of the hidden attribute can be recommended, until that point the recommendations outlined above will have to suffice.

Examples: a button and a link

Developers have had for 11 years number of native elements they can use for buttons and the a element for links, provided in HTML 4, all of which provide built in mouse and keyboard interaction and convey role, state and name properties to accessibilityAPIs:

• input type="button"
• input type="image"
• button element
• a element

But still in 2010 companies like Google, choose to emulate a button with code (not to mention the associated scripting) such as this:

<DIV id=:rk class="J-K-I J-J5-Ji L3 J-K-I-JO" tabIndex=0
unselectable="on" closure_hashCode_l16mgm="182" act="">
<DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV>
</DIV></DIV></DIV></DIV>

and a link like this:

<SPAN id=:rg class=toxOdd role=link tabIndex=0 closure_hashCode_l16mgm="177">
Create a filter</SPAN>

Note: Examples are taken from Googles Gmail application.

The reason is probably because they cannot apply the styles they want to native interactive elements, but who knows? What is important for accessibility is if developers choose to code in this way, they now have a method to provide the needed accessibility information. It would be preferable that they used the available native HTML elements, but if they do not, then ARIA provides what HTML alone cannot.

Further reading:

• Clean markup plea : Anne van kesteren ramps up the rhetoric on the issue.
• HML5 and WAI-ARIA: Alastair Campbell explores the issue further.

Aria roles and properties not available in HTML5

Below are listed the ARIA roles and properties. Those roles and properties suffixed with a “+”  are features not considered to be available natively in HTML5. It is clear that many roles and properties provided by ARIA which can be used to convey information to users are not available in HTML5.

ARIA Roles

5.3.2. Widget Roles

The following roles act as user interface widgets that do not provide a defined structure. All roles are linked to their definitions in the WAI-ARIA 1.0 specification.

• alert +
• alertdialog +
• button
• checkbox
• combobox
• dialog +
• gridcell +
• link
• log +
• marquee +
• menuitem
• menuitemcheckbox
• menuitemradio
• option
• progressbar
• radio
• radiogroup
• scrollbar +
• slider
• spinbutton
• status +
• tab +
• tabpanel +
• textbox
• timer +
• tooltip +
• treeitem +

The following roles act as composite user interface widgets that provide a defined structure. These roles typically act as containers that manage other, contained widgets.

• grid +
• listbox
• menu
• menubar
• tablist +
• toolbar
• tree +
• treegrid +

5.3.3. Document Structure

The following roles describe structures that organize content in a page. Document structures are not usually interactive.

• article
• columnheader
• definition +
• directory +
• document +
• group +
• heading
• img
• list
• listitem
• math +
• note +
• presentation +
• region +
• row
• rowheader
• separator

5.3.4. Landmark Roles

The following roles are regions of the page intended as navigational landmarks.

• application +
• banner +
• complementary
• contentinfo +
• form
• main +
• navigation
• search +

ARIA States and Properties (all aria-* attributes)

Below is an alphabetical list of WAI-ARIA states and properties to be used by rich internet application authors. A detailed definition of each WAI-ARIA state and property follows this compact list.

“Embedding accessibility support into widely used toolkits like jQuery is essential in order for people with disabilities to take full advantage of services delivered via web applications built by AOL and developers around the world,” said Tom Wlodkowski, AOL’s accessibility director. “Our goal is to minimize the barriers application developers confront today in making rich web interfaces accessible.”

The initial focus of the AOL/TPG partnership is to assess the current level of accessibility of jQuery user interface (UI) components. TPG will then contribute JavaScript code to address gaps in accessibility to the jQuery community. AOL uses jQuery extensively and will leverage the accessible components in future consumer-facing web applications. When released in the next version of jQuery, any developer using the toolkit will inherit these accessibility enhancements.

“TPG is excited about our partnership with AOL,” stated Mike Paciello, founder and president of The Paciello Group. “We see this as an incredible opportunity to influence the usability of next generation web applications and to promote the inclusion of users with disabilities. By enhancing the jQuery developer toolkit, developers will have the framework for building accessible and usable rich internet applications.”

This project is also supported with the financial contribution of the European Commission in the context of the ÆGIS project (Open Accessibility Everywhere: Groundwork, Infrastructure, Standards). The AEGIS project is focused on the research and development of solutions to advance accessibility of mainstream ICT (desktop, rich Internet and mobile applications).

For more information, please contact Brian Landrigan.

Please refer to the US Access Board web site for additional details.

Last night I confirmed with the US Access Board that the version of the guidelines to be released in March are an “Advance Notice of Proposed Rulemaking (ANPRM)”, with a 90-day period for public comment.

It is important to note that this Advance Notice is a step BEFORE a Notice of Proposed Rulemaking (NPRM). The Advance Notice is being provided in the interest of getting material out to the public in a timely manner. This Advance Notice allows draft text to be released. After public comments are received and reviewed, a Notice of Proposed Rulemaking will then be released, after preparation of a regulatory assessment, as well as a full Preamble. The date of the NPRM is not known at this time.

An official notice will appear in the US Federal Register when draft text is available.

Note that the US Access Board will be holding a special session at this year’s CSUN conference in San Diego. Members of the public will be invited to speak during the event. Everyone is encouraged to attend.

You can find CSUN on Facebook.