RE: [WebAIM] More data on accesskeys (New article written Nov. 1)

Lachlan Hunt wrote wrt validation:
> That sounds like bureaucratic, political nonsense.

Yep, but it's very common. In the UK at least has helped get things
moving on accessibility. (E.g. the top 100 government sites have better
accessibility than the top 100 corporate sites, which tend to take a
less political, less bureaucratic approach.)

> It makes me glad that HTML 5 dispenses with useless DTD based
validity.

For those who haven't memorised the latest specs (99.9% of the web
development population?), being able to validate your markup is very
re-assuring, especially when being produced by a complex system. It is
for me at least. Is that what you meant, or can you check for
well-formedness regardless of DOCTYPE?

> Can you send me a link to the implementation and test cases 
> for it?

http://firefox.cita.uiuc.edu/test/ts-test-page-role.php
(It's under the DHTML button once you've installed the beta, not
navigation as I assumed.)

> The role the link plays here would be role="navigation".  
> However, the 
> <nav> element says it's part of the site naviation, the 
> <menu> says it's 
> part of a navigation menu and the <a> says it's a link.  In 
> this case, 
> role="navigation" provides absolutely no additional information 
> whatsoever.

I followed the set-up of WHAT-WG, but I have to admit that the setting
up new elements like <nav> and <article> was news to me. Functionality
wise it would overlap considerably with the proposed use of the role
attribute.

This is an important point with regards to the mechanism chosen for the
next-gen accesskey mechanism. I can't see them being mutually exclusive
(i.e. a UA could support both role="nav" and <nav>), but what is the
coverage like for each? (I.e. how many different concepts do each
cover?)

> >> <label for="...">Foo <a href="#help-foo" 
> rel="help">(help)</a></label>

Interesting, I guess a little bit of unobtrusive JavaScript could call
the content up without moving off the form. It also gets around help
being outside of the normal tab order, although I'd like to test it with
people in case there's something I haven't thought of.

There is a lot to be said about using aspects that are already in the
mark-up, and there seem to be two primary use-cases that we are talking
about:

1. Within page navigation. This could be where the purpose of different
sections is declared in the body markup (with elements like <nav> or
role="navigation"), or it could be with <link>s in the head of the
document.

2. Site navigation short-cuts. E.g. <link> in head to the contact page.

Although the user need not care, I do see within-page and site-wide
navigation as quite different, because pages can change from section to
section, but the site-wide navigation should be consistent.

In terms of ease of implementation for a site, and maintainability,
using aspects you are already including in the markup is great, +1 for
HTML5's new elements. With regards to site navigation, I'm not overly
happy with having to declare site-wide navigation on a per-page basis
(as David Wooley remarked). 

Could we use a link in the head that goes to a static (cacheable) file
for site-wide navigation? I know you could use a server side include,
but it seems kludgy, as you are still sending (potentially) quite a lot
of HTML with every page.

With regards to <link>s under-use, unless someone makes a pluggin for IE
or it supports it natively, it is unlikely to change. Unless of course
Opera or Firefox become the defacto browsers for people with
accessibility issues ;)

Kind regards,

-Alastair

-- 
Alastair Campbell         |  Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

Received on Monday, 6 November 2006 10:15:36 UTC