E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Access and role

Number of posts in this thread: 2 (In chronological order)

From: John Foliot - WATS.ca
Date: Fri, Aug 12 2005 11:12AM
Subject: RE: Access and role
No previous message | Next message →

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" />

<access title="Site Search" targetid="search" />

</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 ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053

From: John Foliot - WATS.ca
Date: Fri, Aug 12 2005 11:12AM
Subject: RE: Access and role
← Previous message | No next message

Glenda Watson Hyatt wrote:
> Thanks John,
>
> I appreciate your detailed explanation. It'll take a bit to digest
> this.
>
> To really simplify this, is the bottom line: the web developer will
> identify various access points and the visitor can specify how to get
> there [ie by defining their own keyboard shortcuts]?
>
> Cheers,
> Glenda
>
> Glenda Watson Hyatt, Principal
> Soaring Eagle Communications
> Accessible websites. Accessible content. Accessible solutions.
> www.webaccessibility.biz
>

Essentially yes, although user agents can also (and probably will) have
pre-mapped keybindings for the common (standard?) roles. For example,
Opera, which is already a very keyboard-user friendly browser may ship
"pre-wired" for the collection of these common roles. Adaptive
technologies may also come pre-configured for the same common roles, so
that in JAWS for example, ALT+Q (for query) might be pre-mapped to the
role of "search". The advantage here of course is that on "every" site
that has a defined role="search" (or even id="search") then the
keybinding works - every time! I personally envision this type of AT
functionality first, followed closely by Opera and possibly Firefox
implementing - with I suspect the ability for end users to define their
own custom bindings as a strong part of those implementations. (Chaals
might make a liar of me and see Opera be first off the block...)

Where it might get tricky is in the custom role declarations - then,
because they will essentially be "new" roles to the end user, a means of
auto-discovery will need to exist, along with the ability to create
bindings on the fly. For example, you just visited the
www.wackywidget.com website, which has created a custom <access> of
"glossary". To do so, the author must create an RDF reference which
"defines" what "glossary" means. But for the end user, how will they
know that there is the possibility to create a binding to "glossary"?
This will probably be the job of the user agent - but the actual "HOW"
is left open. One method might be for sites to set cookies to store
these custom bindings, with a null value for the action generating an
alert of some sort. Vague and loosey goosey right now...

What we, the accessibility community need to be discussing is the list
of common roles (I listed them in the first response, and they are
listed in the draft as well). Are these enough? Are there any missing?
Which is better, "navigation" or "toc" (table of contents)? Or should
we have both as they in fact may be separate ideas/items? I'm not a big
fan of "contentinfo", as for the most part this is essentially "footer"
info... So why not call it that? What about the role(s) of "policy",
"accessibility", "alternative"? I can envision all of these having a
place in the developers/authors toolbox. Are there any others which
should be part of the common collection? [invitation to discuss]

It makes sense really, as once again we are separating the "logic" or
semantic structure from the behavior and presentation. Authors declare
specific roles, but leave the method of quickly accessing (or navigating
to) the role to the end user and their tool(s) of choice.

See, I always supported the idea, just not the existing
implementation...

Cheers!

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