Accessibility Camp DC

[zvi]

I went to Accessibility Camp DC on October 10, and I got swamped with a lot of information. I haven't absorbed all of it, but I wanted to do a write up and share what I could parse out from my notes and a lot of URLs that I hope will be helpful. Other attendees have shared their presentation slides and blog entries and the conference provided a variety of accessibility links.

One of the sponsors of the program was DC's Martin Luther King Library Adaptive Services Division. I don't know how many people are close enough that getting there is useful, but the library has a wide range of accessible software and devices that they allow people to use, so if a DC-area developer or designer in the area needed or wanted to test how their component actually functions with adaptive technology, going there is a possibility.

The practical advice that I walked away with was this:

• In addition to making our user facing tools accessible, we should also work on making the administrative tools accessible
• We should develop or adopt best practice policies, so that developers and designers know what we expect them to do to make our tools and website accessible before they start creating an interface, instead of designing the tool and then bringing it here to get checked
In that vein, basic accessibility for screenreader users requires that
• Form fields have labels
• Links have meaningful text
• If information is popped-up or brought forward with ajax/javascript/ruby, etc., it should be brought to the attention of the screenreader and manipulable via keyboard and other non-mouse devices
• tabindexing should be explicitly declared if the default reading order does not make sense, but it's best if the default order of links (by which is meant the order that they appear in the HTML code, which can be very different from the appearance of a graphical browser with CSS and javascript turned on) makes sense
• The best way to get our users to generate more accessible content is to give them tools that prompt them for accessible choices and explain why they should make those choices, as they make the content.
• Keyboards are not the only alternative input device to the mouse. (Unfortunately, the gentleman who made this statement didn't expand on what other input devices one might design for.)

I also got a bunch of links. The most important one for Dreamwidth, I think, is to the Authoring Tool Accessibility Guidelines. These guidelines focus on making the tool themselves accessible and creating tools that generate more accessible content. This is a very technical document.

The WCAG 2.0 Documents

The Web Content Accessibility Guidelines are the W3C recommendations for Accessibility. They have several interrelated documents which offer different kinds of technical guidance, from general principles to a quick accessibility techniques reference.

Just Ask: Integrating Accessibility Throughout Design

This is not a design book and it applies to electronics and technology generally, as opposed to Web and Internet technologies exclusively. It's about how to integrate people with disabilities into the design process.

Validator.nut

This validator will check HTML5 and ARIA in the same document. For the moment, the W3C validator marks ARIA markup as invalid.

WebAIM

WebAIM's mission is to expand the potential of the web for people with disabilities by providing the knowledge, technical skills, tools, organizational leadership strategies, and vision that empower organizations to make their own content accessible to people with disabilities.

WebA11y

A personal website by Becky Gibson, Web Accessibility Architect at IBM, which has some demonstrates of accessible AJAX and RIA=ARIA.

System Access To Go

Windows only, internet based screenreader. It involves a download. I don't know the size, as I use Linux.

One presentation I attended was on performing an accessibility audit. The presentation was by employees of a company which performs accessibility audits and consulting, so it was geared for a more corporate set up with a large number of people to pull from, but here are my notes. One point of interest: the company has an automated testing tool, AMP,, which it offers in either a free trial or a free community edition, I am not clear which. In any case, my transcribed notes follow:

Good Accessibility audit
1. Automated testing
2. Manual testing (review of code and simulations of disabled user experience)
3. Use case testing

Use case testing is to see if the system functions for disabled users or with a particular accessible technology. Usability testing is examining how well the system works.

Best Practices
• Confined set of criteria
• Repeatable results from tester to tester
• Based on standards, i.e. WCAG 2

Unit based testing
• Identifies patterns
• highly accurate
• makes it easy to point out what media types to correct and clearer how to correct them

Unfortunately, I didn't put in my notes what a testing unit is, and I no longer recall. It was one of two things, either about how one organized the testing team or about how one organized the system for testing, but I really don't remember anymore. My apologies.

Comments

[denise]

Keyboards are not the only alternative input device to the mouse. (Unfortunately, the gentleman who made this statement didn't expand on what other input devices one might design for.)

The ones that come to mind immediately: voice control, and tongue-switches.

[onceamy]

Keyboards are not the only alternative input device to the mouse. (Unfortunately, the gentleman who made this statement didn't expand on what other input devices one might design for.)

One handed keyboard layouts (DVORAK can be a one handed layout), toeboards (I think they're called, anyway)...

This is an interesting gathering of links! I'm going to pinch it for the OTW's AO3 accessibility review, with thanks and credit.

[kyrielle]

Alternative input devices: touch-screen, tablet. (Though these are mouse-plus-others in terms of types of features, rather than more restricted, I think.)

[zvi]

well, but tablets and touch screens may or may not support 2 or 3 buttons