WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Access and role

for

From: John Foliot - WATS.ca
Date: Aug 12, 2005 11:12AM

Glenda Watson Hyatt wrote:
> I'm trying to wrap my head around 'access' and 'role' as a
> replacement for accesskeys. How does this work? Can someone
> explain it in very simplified terms, please?
>
> Cheers,
> Glenda
>
> Ps I'm not looking to rehash the "accesskeys don't work" discussion.
> I want to understand the new approach in simple terms, please.
>
>
> Glenda Watson Hyatt, Principal
> Soaring Eagle Communications
> Accessible websites. Accessible content. Accessible solutions.
> www.webaccessibility.biz


First, start with the Draft Spec:
http://www.w3.org/TR/2005/WD-xhtml2-20050527/

...and specifically:
http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule

[Now... Sorta think of named anchors intra-page navigation...]


1) The "access" element assigns an accessibility mapping to elements
(containers?) within a document. It is declared in the <head> element.
This element has a number of optional attributes, including "key"
(Grrr), targetid, targetrole plus the "common collection" (which
includes attributes such as lang, bi-directional instructions, etc.)

2) The "role" attribute identifies said elements (containers?). From my
understanding, the role attribute can be assigned to any other element,
from structural <divs> to specifics such as form text inputs.

3) There is a pre-defined collection of Roles:

main - This defines the main content of a document.

secondary - This is any unique section of the document. In the case of a
portal, this may include but not be limited to: show times; current
weather; or stocks to watch.

navigation - This is the navigation bar on a web document. This is
typically a list of links to other pages on the site or other areas of
the same document.

banner - A banner is usually defined as the advertisement at the top of
a web page. The banner content typically contains the site or company
logo and other key advertisements for the site.

contentinfo - This is information about the content on the page. For
example, footnotes, copyrights, links to privacy statements, etc. would
belong here.

note - The content is parenthetic or ancillary to the main content of
the resource.

seealso - Indicates that the element contains content that is related to
the main content of the page.

search - This is the search section of a web document. This is typically
a form used to submit search requests about the site or is a more
general Internet wide search service.

(Remember, this is in Draft...)

4) Unique roles not already defined in the spec can be defined via RDF.

Code-in-a-nutshell:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Access Explained</title>
<access title="Table of Contents" targetrole="navigation" />
<access key="m" title="Main content" targetrole="main" />
<!-- I still argue that the key attribute should not even be allowed,
however... -->
<access title="Site Search" targetid="search" />
<!-- note this last element references a targetid rather than a
targetrole -->
</head>

<body>
<div role="navigation">
navigation code here
</div>

<div id="main_content" role="main">

<form action="foobar">
<label for="search">Search:</label>
<input type="text" name="search" id="search" size="10"
maxlength="50" />
</form>

</div>
</body>
</html>

<opinion>
I personally feel that leaving the "key" attribute into the spec is a
mistake, as it allows authors the ability to continue to map conflicts,
knowingly or unknowingly. However there is a feeling that this
requirement is still needed (although the justification is, IMHO, flimsy
at best).
</opinion>

The current thinking is that there will be a "cascade" resolution
mechanism which should address any conflict issues:

1) User-defined bindings take precedence over all other
declarations.
2) User agent bindings take precedence over author declared
bindings.
3.1) Author declared bindings are exposed when no mapping is
previously declared.
3.2) User agents announce the availability of a keybinding and
allow for user mapping if desired.

It was further suggested to me that the web-accessibility community
should then support a "best practices" to a) implement the common roles,
b) avoid specific keybindings. It also now puts an emphasis on the user
agents to deliver the functionality we seek using this new method.

As this is still all new, it is somewhat difficult to develope a working
example - however the code sample above should be compliant and
"workable", if rudimentary.

Hope this helps

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053