accessibility

I followed up on a bug report about accessibility issues and radio buttons. Created the patch and had it approved by the test bot and others that reviewed the code.

However I'm requesting support from the accessibility community to see if we can't bring it into Drupal 7 core.

Form labels for radio & checkbox(s) are not properly done with Drupal at the moment and don't follow WCAG 2.0 Guidelines.

We've been discussing the need for unique strings of text for unique links in the new WCAG 2.0 standards. But Cliff brought up that there are some SEO issues involved in this as well. So how do we get more meaningful links coming from our list/view pages so that instead of having 100 links pointing to your page say "Read more" and we have more using a related string, like "Accessible Themes for Drupal".

In a recent WCAG 2.0 presentation I was attending it was stressed that websites should not be using the same text to link to different URL's. So, with a generic Drupal blog when the teaser node produces 10 or so "Read more", "Add new comment" or "Send to friend" links, each going to unique URLs for the corresponding post it becomes very difficult for screen readers to navigate.

In an accessibility blog post I wrote about quick accessibility enhancements, I described an easy way to make the Read more link more descriptive. I believe it's also got some both SEO & click through advantages too.

Beim Web Standards Project habe ich von Web Standards Cafes gelesen. Dabei treffen sich Webdesigner und -entwickler um sich über "HTML, XHTML, XML, CSS, XSLT etc." und auch best-practices auszutauschen.

This issue cropped up recently (I am not sure if it has been discussed elsewhere or even resolved). If it has please let me know. With the advent of version 6 a couple of my vision impaired friends have told me they find it much more difficult to use blocks in version 6. This has resulted in some of them going back to using version 5.*. This issue concerns the keyboard accessibility of blocks. i believe there has been a move towards a "drag and drop" model with blocks when re-ordering page content.

Blind people, when using screen readers or refreshable braille displays, must read web pages sequentially. Typically this means plowing through the page navigation before reaching the main content.

We can provide helpful links, links which are noticeable only to people using non-visual browsers, which allow them to skip over the navigation. It's really easy.

<a class="accessible" href="#bmain" name="btop"><img src="/files/spacer.gif" width="1" height="1" alt="Skip to main" /></a>

Ever used GIFs to display that cool font on a website? You hope it doesn't effect your search ranking and accessiblity, but the customer is adamant that the design comes first.

Gordon Heydon mentioned this thing called Scalable Inman Flash Replacement or sIFR. Apparently some drupallians are using it (eg. Bryght). I had to find out more.

There is set up a small testing site for themes at http://theme.drupaler.net/.

I've tried to install all available themes (4.7.2) and categorized them according to their validatation against "Markup", "CSS" and "WCAG".

All Installed themes can be easily tested from a "Test [$theme]" link. If you are registered you are able to vote for a theme.
If a theme is missing, you should post a story with the [$theme].tar.gz

As I've started "W3C compliant CSS"-issue (http://drupal.org/node/70296) as a wish, it was the first one in the chain of validitaion.

The main critism of warning-free css-validation is the "inherit" argument, which changes nothing visible, but is needed by W3C-validation (warning free).

In my opinion there is a difference between an "explicit defined default" and an "undefined default", cause the "explicit defined" says: Yes, I'm sure, that I want to do this.
As we are experienced webusers, we know that the warning of "undefined color" doesn't make visible sense. But it's one of my most-hated questions customers asks me twice a month: "Why does your site so much validation warnings, although you are working active for accessibility?".

Once upon a time ... there was an idea to do it here: http://openusability.org/projects/drupal/

What's about these plans?