Accessibility

By using CSS's "media" attribute we could provide customized CSS for different end user devices (browsers, screen readers, Braille devices, etc.) without interfering with other devices' style sheets.

Following the suggestion at Accessibility improvements for vertical tabs here's a page to collect some of the scattered information on keyboard navigation.

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.

There is currently an open issue in the d.o issue queue Add colouring (and description) to password checker (#331893). The issue hasn't received much attention lately and I am curious what thoughts there are from usability and accessibility folks on the proposed patch in comment #36.

This patch essentially tests the password strength and displays a growing colored bar which changes colors depending on password strength. The patch also displays text to represent the strength of the password.

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?

Within the Drupal menu system descriptions can be added to menu items. These descriptions are often presented as tooltip text through setting the title attribute of the menu item anchor to the value of the menu item description. One example of this can be seen in (Issue #510094) Add description to the link items of the toolbar.

Present on the call

• Mike Gifford
• Everett Zufelt
• Brandon Bowersox
• Valeria Brigatti
• Rob Russell
• Jeff Burns

One week to Code Freeze

On the call we discussed the fact that there is only one week remaining until code freeze. Because of this certain issues need to be prioritized. Some of the current issues in the queue will be able to be fixed after code freeze, others unfortunately will not be fixed for the Drupal 7 release.

Autocomplete

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:

I posted this awhile back on the Nice Menus issue queue with no response. Wondering if perhaps I am doing something wrong on the accessibility testing front (using WAVE to check site)....or if someone else has experienced this issue as well:

Glad to see that there is now a Drupal Group for National/Federal & State/Province Drupal installs as well as the previous one for Local Governments. I had tried to set up a general Government Group, but for some reason at the time it was rejected.

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>

Here is the post from drupal.org that I mentioned at the Surrey meetup yesterday. In the comment a Drupal user states he is blind and that TinyMCE is the best editor for blind people because of it's accessibility.

http://drupal.org/node/241753#comment-1593072

Izzy

On Monday, August 10, we had the second of three planned Drupal 7 accessibility taskforce conference calls. The goal of this call was to discuss open accessibility issues, and to brainstorm and build consensus on appropriate solutions.

Present on the Call

<

ul>

This morning I took a first look at the d7ux administration theme "Seven" from the perspective of a screen-reader user. Overall I found the theme enjoyable, but there is more work to be done to ensure that the theme is truly accessible.

You can read my blog post about the accessibility of Seven at http://openconcept.ca/blog/everett/first_glance_accessibility_evaluation...

Next Conference Call

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

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

On Monday, July 27, we had the first of three planned Drupal 7 accessibility taskforce conference calls. The goal of the call was for those interested in Drupal 7 accessibility to be introduced to each other, and to develop consensus on several fundamental issues surrounding Drupal 7 accessibility

Present on the Call

• Mike Gifford
• Everett Zufelt
• Katherine Lynch
• Brandon Bowersox
• William Lawrence
• Kathy Kahl
• Ann McMeekin
• Valeria Brigatti
• Owen Barton

Apologies

The other day I posted to the accessibility group on g.d.o and was asked to solve a CAPTCHA. As a screen-reader user, posting in an accessibility forum, I was quite surprised.

Now, I was made a little less frustrated when I noticed that the CAPTCHA included an audio alternative. However, the audio is sufficiently unclear that it was a challenge for me to solve on the first attempt, and I cannot imagine the challenge it would be for someone who is hearing impaired.

In short, audio / visual CAPTCHAs, even when used together, are a poor accessibility practice.

Hi there!
In the last summer term I had a course on web accessibility here on the University of Linz (Austria). Unfortunately there is only one really useful resulting project. I made Drupal7 the topic of all exercises.
In the attached project you can find testing and some redesign suggestions (without any php coding). The project is limited to only 6 sample pages, but it could be interesting. The student has allowed to publish his results for Drupal community.