Nov 29th - Dec 1st I attended the Web Accessibility Capacity Building Institute (CBI) organized by DO-IT.
(pictures taken by Rick Ells)
The institute has a blog that contains opinions arrived at via group discussions and some additional content I won’t link to from here. Rick Ells, whom I heard about the institute from, is likely to publish his notes at some point. When he does, I’ll link to them.
Web Apps - The Next Generation: Access Opportunity or Challenge
T.V. Raman, Google
- Users without normal use of vision install multiple screen readers - writing web pages or applications for a specific screen reader is inappropriate
- Assistive Technology (AT) like screen readers assume a desktop application model. Browsers are presumed to display static pages. Rich applications running in a browser can confuse AT.
Access Goals
- retain the present level of access
- increase reach with wider access
- accessibility to more users
- accessibility in more contexts
Access Building Blocks
- Content: include adequate semantics
- User Interface: degrade gracefully
- AT: bridge the gap
If something is a menu, say so! People unable to see that it looks like one won’t know otherwise.
What to speak: Content should be separate from format and controls.
How to speak: Aural CSS
When to speak: Event handlers allow spoken feedback to reflect visual updates
RSS is good for accessibility. It’s well-structured and provides a minimum of understandable content.
Community-based captioning may be a good solution for making uploaded video accessible.
Including open APIs in web tools is perhaps the best way of supporting accessibility for those tools, as those affected or in-touch with the challenges of accessibility are best suited to create accessible interfaces.
Assistive Technology Vendor Panel
T.V. Raman, Google
Doug Geoffray, GW Micro
XSL scripts in emacspeak can be exchanged within a community as greasemonkey scripts are, providing a network effect that allows users to simplify their web experience.
The “threshold of indignation” between blind and sighted users is very different. This is why sighted users that attempt to navigate the web via a screen reader alone will become frustrated very quickly.
Macs using OSX Tiger or later include voiceover, a built-in AT application.
W3C Roadmap for Accessible Rich Internet Applications
Rich Schwerdtfeger, IBM & W3C Web Accessibility Initiative
XForms will enable much more accessible web applications and richer form and interface elements. Hopefully browsers will include support for this soon.
Presentation
W3C Web Content Accessibility Guidelines 2.0
W3C Dynamic Accessible Web Content Roadmap
Management Panel: Policies, Practices and Processes for Maintaining Accessibility
Bill Corrigan
Cheryl Hammond
Wei-zhong Wang
- The legal threat of inaccessible paperless systems required to complete job tasks may drive change in accessibility.
- How can podcasts be made accessible?
- Many Captchas aren’t accessible.
- Alternate solutions include integer addition and audio captchas.
- Try replacing images on a page with their alt text in order to test them for understandability.
- Don’t assume that your pages & apps are accessible when they meet a standard.
Accessibility of Rich Adobe Applications
Bob Regan, Adobe
Some of the applications presented are quite a bit more accessible than I expected Flash could be.
Bob has developers use a screen reader for an hour every day for 3-6 weeks in order to give them a feel for how to write applications that will be usable via screen reader.