Need accessibility feedback over in docs

[rho]

Hello wonderful accessibility team!

We're in the process of designing an entirely new FAQ system at the moment, and one of the things that I'm keen to do is make sure that we have accessibility considerations built in from the start. Unfortunately, I'm not at all knowledgeable when it comes to accessibility, so I don't know what we need to be looking at. If you could go take a look at this entry from dw_docs where I have a first draft version of the specifications for the new system up, I'd appreciate it. I need to know:

1. What of the current spec will be bad for accessibility.
2. What of the current spec have I managed to get right, accessibility-wise.
3. What have I just not thought of at all that needs to be added in.

Thanks!

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 )