Cross-posting [was: [WebAIM] More data on accesskeys (New article written Nov. 1)]

The content from this thread is interesting, but it would be better to
post it to just one list. I've deleted dozens of redundant messages now
from as many as three lists that have been posted to.  Please?

Thanks,
AWK

> -----Original Message-----
> From: w3c-wai-ig-request@w3.org 
> [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Alastair Campbell
> Sent: Monday, November 06, 2006 5:09 AM
> To: Lachlan Hunt
> Cc: WebAIM Discussion List; w3c-wai-ig@w3.org; John Foliot
> Subject: 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 15:20:02 UTC