accessibility

In random order, rough, wrote as making changes. Most interesting is the aria-required and adding the h2's to status messages, etc.

If using beauty tips, beware of using non-100% opacity due to those with visibility issues.

Add h2's around messages and role alert.

What if your site is perfectly accessible but no one knows about it?

This question came up while working on Accessibility improvements for vertical tabs , together with some first thoughts on this issue.

You all might remember an earlier post I made about the QUAIL accessibility library and its potential for checking content for accessibility. Well, now you can download the fruits of that labor!

There's a readme file in there that outlines how to download and setup the module. It comes packaged with the quail lib for now, but if it goes to drupal.org I'll remove it and require folks to download it from it's own site on code.google.com.

Visualize is a Views style plug-in for implementing the jQuery Visualize charting tool.

jQuery Visualize provides accessible charts providing textual information to non-visual users.
It uses a technique with JavaScript to scrape data from an HTML table and generate charts using the HTML 5 Canvas element.

Try out a demo: http://lakeandweb.com/visualize/

We need to come up with a good name for a CSS class, but I don't want this discussion to clutter up the issue queue. (Let's reserve the queue for presenting and discussing patches that fix functional or programmatic problems.) So I'm posting this item to see if we can develop an idea that is better than the ones we've already come up with.

In case we're interested in taking this into IRC, I registered #drupal-accessibility on freenode to chat around coding and accessibility issues and extensions in Drupal.

I'm going to set up logging on it this weekend.

Mike Gifford (mgifford) and Everett Zufelt are addressing a major accessibility issue for the administration interface of Drupal 7. If they had help from someone with JQuery skills, they could make significant progress. If you think you can help, check out http://drupal.org/node/467296.

The semantic structure of a discussion can be ruined if a comment includes code for headings that are at a higher level than the title of each comment. In discussions in Drupal, the title of the page is an <h1>, key regions are headed with <h2>s (which sometimes do not appear on screen but are available to screen readers to define regions that are obvious on visual inspection), and each comment begins with an h3. So if any heading is added within a comment, it should be no higher than an <h4>, right?

The 'Find Content' form has a prominent place in Drupal 7. However, the form poses accessibility challenges. The filter form is composed of radio buttons and dropdowns that visually correspond for sighted users but there is no indication they correspond for screen-reader users.

I've proposed a change to the Find Content filter form. I'm seeking feedback here and in issue #551034. I believe the change is a win-win for accessibility and usability.

Here is a screenshot of the proposed form:

Next Conference Call

Monday August 24
11:00am Eastern Time (U.S.) (-05:00 UTC)

If you want to participate please e-mail
everett@openconcept.ca

Agenda

Please feel free to add agenda items.

• Discuss solutions to outstanding problems listed in Everett's blog article Update to the State of Drupal 7 Accessibility.

Participants

<

ul>