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

John Foliot wrote:
> XHTML 2 will deprecated accesskey in favor of the access element, which will 
> take attributes such as @role and @ key (to which I am extremely concerned: 
> if you have not already seen my piece "Access + Key Still Equals Accesskey" 
> [http://www.wats.ca/show.php?contentid=47],

FWIW, at this stage, it seems XHTML 2 probably isn't worth worrying 
about too much, given that major browser vendors are showing little to 
no interest in it whatsoever.  Also, you might be interested to know 
that the (X)HTML 5 draft currently does not include accesskey for links.

http://www.whatwg.org/specs/web-apps/current-work/#the-a
http://www.whatwg.org/specs/web-apps/current-work/#the-link

Although, for some reason, it's still included for form controls, but I 
don't know why yet.

http://www.whatwg.org/specs/web-forms/current-work/#accesskey

> Joe Clark rants about [http://blog.fawny.org/2006/10/28/tbl-html]

Regarding the suggested HTML improvements listed in Joe's article, we're 
currently discussing several of them over on the WHATWG list for 
possible inclusion in HTML5.  We'd really appreciate feedback and 
suggestions, particularly about the accessibility enhancements.

http://www.whatwg.org/mailing-list

> Is there anybody out there comfortable enough to hack a modified DTD 
> together so that @role could validate today?

Does it really matter that much?  DTD based validation is just a tool, 
and just because it reports an unknown attribute, it's not going to 
affect the accessibility of the site.

Andy Mabbett wrote:
> A simple fix for the problem of access keys would be to allow the user to 
> define their own access keys for, say, "home", "search", [...], etc.; and 
> then to map these, for any given page, to the target pages specified in 
> the "link" headers, e.g.:
>  
>         <link rel="home" href="http://www.example.com/index.htm">
>         <link rel="search" href="http://www.example.com/search.htm">

I agree with the concept, but I don't agree with using the <link> element.

The follwing list of access keys has been taken from Gez's recent 
article.  Along with each, I describe a suggestion for how it can 
already be hanlded using HTML4 markup or the drafted HTML5 markup.

* S — Skip navigation

   <nav>, <menu>, etc. allow the UA to clearly identify the navigation, 
which can then be skipped using a UA defined key.

* 1 — Home page

   <a href="/" rel="home">[LOGO/NAME]</a>

http://microformats.org/wiki/rel-home

Are there any existing shortcut key implementations which take the user 
back to the root directory of the site?  Because, in many cases, the 
home link will usually be either "/", "/index.htm" or equivalent (for 
which navigating to "/" will be just as effective).  So perhaps 
rel="home" is a little redundant here, and would be more useful where 
the home page isn't the site's root directory. e.g.

http://example.com/~username/

Where the home link would point to "/~username/" (or equivalent).

* 2 — What's new

   Is there a strong use case for identifying links to this?  These 
days, new information is often provided through RSS/Atom feeds.  I'm not 
really sure what kind of content this would be used for, so I can't 
really suggest anything.  That's why I'd need to know the use cases.  If 
it's just news, maybe <article> would do the trick?

* 3 — Site map

   rel="index", rel="contents" ???

* 4 — Search

   rel="search"

I'm not aware of any definition of rel="search" anywhere, including 
HTML4, microformats.org, or elsewhere.

A related issue is that of identifying search forms on pages.  I'm aware 
of role="search", but at present, HTML5 is not including the role 
attribute because, AFAIK, there aren't sufficient use cases to justify 
it.  (see below).  Would <input type="search"> be useful for this? 
Safari has already implemented that.  If strong use cases could be 
provided for it, it could be considered for HTML5 (Web Forms 2.0).

* 5 — Frequently Asked Questions (FAQ)
* 6 — Help

When included within the site nav (<nav>), rel="help" can identify help 
for the whole site/page.

   <nav>
     <menu>
       ...
       <li><a href="/help" rel="help">Help</a>
     </menu>
   </nav>

However, when included within a <label>, for instance, it could identify 
help for a specific control.

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


* 8 — Terms and conditions

* 7 — Complaints procedure
* 9 — Feedback form

Maybe somethink like rel="contact"?


*The Role Attribute*

As I mentioned above, HTML5 currently doesn't include the role 
attribute, though it has been discussed on the list several times 
before.  AIUI, the reason is that, given it's current definition and 
values, HTML5 covers many of the use cases with new elements.

http://www.w3.org/TR/xhtml-role/

The following list shows the proposed role attribute values with their 
equivalent HTML5 elements.

* main:        <article>, <section>
* secondary:   <aside>
* navigation:  <nav>
* banner:      <header>
* contentinfo: <footer>
   - For copyrights, privacy links, etc.
   - For footnotes, we're trying to figure out the most effective way to
     mark them up, while considering backwards compatibility as well as
     the drafted CSS3 properties for styling them.

* search:      (see above)
* note         (notes, sidenotes, footnotes, etc. are being discussed)
* seealso      (maybe <aside>, maybe something related to note,
                 maybe someone could explain the use cases!?)

I know role also takes QNames  (e.g. "wai:sitemap"), but they can't 
really be used in the HTML serialisation of HTML 5, because there is no 
namespace support in the syntax.  However, it could technically be in 
XHTML 5 because role is being defined as XHTML Module in the XHTML 1 
namespace, even though it's not included in the (X)HTML5 spec.  There 
are also no DTDs in (X)HTML 5, so validation isn't an issue.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Friday, 3 November 2006 16:50:05 UTC