Working together for standards The Web Standards Project

In web accessibility, you’ll often hear emphasis being placed on the duty of web authors to create accessible content. However, this is only one part of the web accessibility equation.

One that has been particularly close to me, or rather one that has provided me with a lot of opportunity to rant, is the responsibility of developers of user agents.

Any effort on the part of web authors to add accessibility features is rendered useless if browsers and assistive technologies don’t take advantage of them. User agent developers need to ensure that their products support these features and, most crucially, make them available to users in an accessible and obvious manner.

Although far from perfect, the W3C’s User Agent Accessibility Guidelines (UAAG) 1.0 do provide a good starting point.

What follows is a quick run-down of most of UAAG’s guidelines and checkpoints, annotated with comments, suggestions, personal gripes about current levels of implementation, and wishlists for future browser versions.

Admittedly a tad rough around the edges, this is a first attempt at crystallising some of the discussions I’ve had with fellow ATF colleagues, members from the W3C, and other accessibility aficionados.

Read the full article: Current browsers and the User Agent Accessibility Guidelines 1.0.

Your Replies

#1 On May 20th, 2007 11:39 pm Gérard Talbot replied:

Great article (full version) from P. Lauke; I appreciated it.

Things that are missing, either in the UAAG 1.0 guidelines or in the article itself:

- allow user agents to override attributes like noresize (frame), scrolling=no (frame), frameborder=0 (frame): it’s mentioned in the techniques (section 3.7)

- non-resizable secondary window (resizable=no in 3rd parameter of window.open function),

- non-scrollable secondary window (scrollbars=no in 3rd parameter of window.open function),

- allow easy and convenient override (or prevention) of any removal of chrome (toolbars or functionality) of secondary window (javascript-initiated created secondary window)

Another example. In MSIE 6+, an user can not remove the menubar of a normal, standard, non-script-initiated window but a javascript author can remove it in a script-initiated secondary window: a blatant, pure non-sense contradiction where the author has more power than the user.

Firefox and Seamonkey allow a lot of control to users but the user interface (about:config) allowing granular control is far from being an obvious one to figure out: which property does what or controls which feature. One needs to carefully read a long knowledge base article on the attributes/properties configurable in about:config.

It would be interesting to measure the support and compliance of each major browser vendor (Microsoft, Mozilla, Opera, Safari) with their main browser regarding the UAAG 1.0 guidelines. It would show how far they are away from a perfect compliance, therefore showing how much they care about accessibility and would also show how far they are from each other.

Gérard

#2 On May 21st, 2007 6:15 am bruce replied:

Great article, Pat.

The lack of keyboard access to the title attribute is particularly galling, as it means that you can’t rely on the title attribute to inform a user that a link opens a new window as WCAG requires; the keyboard user will never see that title. I’ve got no idea why the browser manufacturers can’t sort this out.

And, of course, who can forget Internet Explorer’s shocking support for keyboard navigation of in-page links.

#3 On June 4th, 2007 7:57 am Beni replied:

Hi Patrick,

I’m a little bit confused about the Part 2.2 in your Article “Provide text view (P1) / The standard “view source” should satisfy this checkpoint.”, maybe my English is not good enough, can someone explain me what is mean with The standard “view source”.

Thanks,
Beni

#4 On June 6th, 2007 6:12 am Robert Wellock replied:

Basically it means delivering the document with a text readable source. Furthermore also having the “fallback” option of reading the original “source code” rather than only being able to view the generated styled markup output of a browser rendered page.

#5 On June 7th, 2007 1:30 am WCAG Samurai Errata Review « WCAG Samurai Peer Review replied:

[...] I don’t think it is wrong to revise the guidelines in this way, assuming that there is some pressure on people producing user-agents to make appropriate updates. [...]

#6 On July 15th, 2007 6:08 am Chris PKV replied:

@ bruce

This I think should be part of the developing on the barrier-free browsing. As I know from several partners and friends we can’t anticipate when and if MS will react and build their IE to display titles (for example) in the required way.

Post a Reply

Comments are closed.