RE: [XHTML-role] How to define roles still needs clarification

On Sun, 2006-11-19 at 17:30 -0800, John Foliot - WATS.ca wrote:

> By access however, I am curious as to exactly what you mean.  The current
> draft is suggesting that creators could assign a keyboard accelerator
> (@key), which I personally have argued strenuously against

I wasn't thinking about keyboard accelerators, especially. Perhaps one
way to illustrate what I'm talking about is to consider BLOCKQUOTE
again. Screen readers usually include a mechanism for distinguishing
text content in a BLOCKQUOTE from surrounding text. For example, you can
configure Window-Eyes to announce the beginning and end of BLOCKQUOTE,
and configure JAWS to read BLOCKQUOTE content in a special quotation
voice. This semantic information also has a navigational aspect, in that
it helps users skip unneeded content. So even the humble BLOCKQUOTE has
a complex set of behaviours created because screen reader developers saw
BLOCKQUOTE in common use and recognized that their users would want
access to that semantic information. Now one might also want to expose
other information about BLOCKQUOTE, such as its CITE attribute. But this
gets really complicated, since the specification doesn't even suggest a
visual treatment of CITE, let alone an aural one. I've seen three
existing implementations of CITE:

1) In Amaya, click on a BLOCKQUOTE with CITE specified and you will jump
to a CITE URI. But whoever designed this functionality seems content
to allow anchor links to override CITE. So when you have, say:

> <blockquote cite="http://www.example.com"><p><a
> href="http://www.anotherexample.com">foo bar</a></p></blockquote>
> 
-- there seems to be no way to access the CITE URI http://www.example.com .

2) In Firefox, right-click on a BLOCKQUOTE, select Properties. You can
now view the URI. If you actually want to go to the URI, you need to
select the text of the URI, copy it to the clipboard (what madness is
this!), and paste it into the address bar. Mozilla gains a point for not
conflating anchors and CITE attributes, and loses a point for making
CITE attributes so fiddly to use.

3) For Opera, there is Arve Bersvendsen's "Enhance blockquote display"
user JS script:

http://userjs.org/scripts/browser/enhancements/enhance-blockquotes

This script inserts the CITE URI as a link after the blockquote like so:

foo bar
-- http://www.example.com

This has the advantage of cleaning separating the CITE URI from the
anchor link, but because it won't have been anticipated it has the
disadvantage of potentially breaking CSS designs.

In the "Hypertextuality" Firefox extension I've been hacking together
( http://www.benjaminhawkeslewis.com/www/svn/hypertextuality ), the
context menu for a cited quotation includes options to open the
quotation source in the current tab, a new tab, or a new window. In the
behaviour for screen readers I've been trying to design,

http://www.benjaminhawkeslewis.com/www/accessibility/how-to-read-q.html

screen readers would announce "cite" before reading a sourced quotation,
theoretically allowing the user to press a hot key to jump to the source
(this is on the analogy of their saying "link" before reading anchor
link text). The ELinks developer looking into implementing the CITE
attribute was talking about adding a focusable [CITE] marker or URI link
text after cited quotations (although ELinks does support some CSS, I
suspect such additions will be less disruptive in ELinks than in Opera).

The point of that nigh-interminable digression was to demonstrate two
things:

1. Exposing semantic information to the user is complex, because
different semantics are best exposed in a variety of ways, but any given
exposition risks conflict with other expositions. Traditionally, this
has meant human beings sitting down and working out a solution, not
browsers magically doing it for themselves. I'm unclear how RDF is going
to help with this. If anything is suggested by the specification as it
stands, it is that we should shunt this responsibility on to the poor
end user, who will be seemingly deduce what actions may be taken on a
given role from its name:

> [The role attribute] could allow a user to make informed decisions on
> which actions may be taken on an element and activate the selected
> action in a device independent way.

This of course ignores how implementation of the existing accessibility
roles is /actually/ happening, which is by browser and screen reader
developers creating specific behaviours for them.

2. When the specification does not actively suggest possible
implementations, more thought has to go into implementations and people
(myself obviously included) are likely to invent suboptimal solutions
because, unlike what does get into the specification, they have not
undergone much in the way of review by the community.

> The W3C has already defined a number of "common" roles
> [http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#col_Role], and
> while this collection may need to be more fully scrutinized to ensure that
> nothing essential is being omitted, once it is complete I cannot foresee
> numerous needs to create new roles - I personally suspect the strength and
> usefulness of @role will come in part from their universality and shared
> understanding, as opposed to their customization.

When you say "numerous needs" that leaves room for there
being /occasional/ needs, which suggests the problem I'm raising
still needs careful consideration. As an aside, if the usefulness of the
role attribute derives from the "universality and shared understanding"
of W3C-defined roles, then logically the creation of new roles should be
restricted to W3C and indeed the roles should surely be fixed when XHTML
2.0 is released, so that /all/ user-agents that comply with XHTML 2.0
can understand /all/ the roles. The RDF stuff would then be completely
unnecessary.

If you're wrong and there many new roles created after the release
of the specification, and there is no provision for defining default
implementations for the roles, then using assistive technology to browse
the web on public computers (whether on the street, in libraries, on
campus, at work) or even using a new piece of assistive technology on
your home machine is going to become enormously time-consuming, as
you'll continually have to break off surfing to define how to handle
each new role. If this is how the WG envisages things working, then it
is imperative that an XML preferences markup language be devised to
complement the roles definition. Such preferences could be gradually
created as you use your assistive technology at home, then synchronized
with an online source and accessed by similar software on public
computers to tell it how to present the roles to suit you.

I think the idea that "nothing essential" will be omitted from the roles
defined by WAI and the XHTML 2 specification itself is over-optimistic
for three reasons:

1) Roles defined by existing assistive frameworks have rarely kept pace
with the evolving complexity of the web. Consider how Mozilla has had to
hack around MSAA's poor support for even ordinary HTML:

http://www.mozilla.org/access/windows/at-apis#knowndif

2) The text of the specification of the roles module expressly introduces
the module as a means to extend the semantics of XHTML-family markup
languages:

> This document is a module designed to be used to help extend the scope
> of XHTML-family markup languages into new environments. It has been
> developed in conjunction with the accessibility community and other
> groups to make it easier to describe the semantic meaning of
> XHTML-family document content.

3) Steve Pemberton describes how the Working Group added the role
attribute for accessibility purposes, then realized that:

> anyone can add their own role values, so that whole communities can
> agree on new semantics to overlay on to the content. In fact this is
> exactly what microformats are about.

http://www.w3.org/2005/Talks/05-steven-xtech/

The proliferation of microformats suggests that there will be widespread
demand for new roles. The role attribute has now become the ultimate
reason not to add any more semantic elements. When people propose the
creation of new semantic elements to this list, they are advised that
XHTML is now about structure not semantics, and that new semantics
should be added by roles. For example, Mark Birkbeck proposed role as an
alternative to a <spoiler /> element:

http://lists.w3.org/Archives/Public/www-html/2005Dec/0014.html

> In this scenario, user-agents will come pre-wired to interact with the
> common collection of roles, allowing the end user to decide (based on
> software/hardware choices and needs) how to interact with the role. 
> This is, to me, the critical key as it gives control to the end user. 
> Content authors should not be telling end users how they must interact
> with the content, but rather simply ensure that the appropriate hooks
> are in place so that the role is exposed in the DOM, and leave the
> "rendering and interactivity" to the user-agent.

Can you (or anyone) give an example of how this might work with a new
role not defined by the XHTML 2 specification or WAI? What does a user
agent require to devise "rendering and interactivity" and what does the
end user require to decide how to interact with a role?

> I am unclear from your examples however how defining a role of "starmap"
> will aid any user.  I would think that it would have an ID (identification)
> of "starmap", but why role?  I can understand what it *is*, but I am unclear
> on what you expect it to *do* or *be*?  Ditto for "price" and "slider"...

Well, exactly. At this point alarm bells should be ringing about how
crucial it is that we clarify the mechanism by which users and
user-agents know what new roles should do or be. :)

> They are things (elements), but are they truly roles in that they have a
> semantic purpose?  A slider is a control, and a visual one at that - what
> does it add to the overall semantic logic of your document? I would think
> that the larger block that contains a slider widget might have a role, but
> the element itself would seem to me to be akin to a form submit or textbox,
> simply tools to achieve something.

With "slider", I was trying to give an example of a role that might be
created for the "thin client form applications" David Woolley mentioned,
but you're right, it was a lousy example, both because the name is too
presentational and because it already exists: XForms includes a "range"
control.

With "price" and "starmap", those clearly have a semantic meaning. A
"price" might be the "price" for a containing element with a role of
"product". Users and their software agents could utilize it in all sorts
of ways: jumping from products to their prices, sorting products by
prices, extracting price comparison data, and so forth. Here's an
example of how it might be used::

> <p role="biz:product"><span role="biz:productDescription">The all-new
> <strong role="biz:productName">W3C Specification Auto-Repair Widget
> 5000</strong> will solve all problems with <em>your</em> draft <span
> role="biz:productKeyword">technical specifications</span>. With just
> one application, it will fill in all lacuna, resolve all confusions,
> magic away all obscure use-cases, and put the whole into language
> readily comprehensible to even the most block-headed of implementors
> and authors! Get your piece of mind now for only <span
> role="biz:productPrice">$1,000</span> and never write an errata
> again!</span role="biz:productDescription">.</p>

Who wouldn't want one? ;)

If you're sceptical about this, have a look at Pemberton's own elaborate
example of marking up the seemingly straightforward sentence "On 8th
June at 14:30,  Steven Pemberton will give a talk entitled Web 4.0:
Now's the Time to Plan at the Web and Beyond Conference." using RDFa in:

http://www.w3.org/2006/Talks/06-08-steven-web40/

How should a "starmap" work? Maybe one would have a <table /> of stars
with co-ordinates and other information, which a visual user agent would
turn into a 3D map. As you focus on a given star, you get details (name,
size, type, age, and so forth) about that star. I suppose an aurally
accessible version of the same would use a quiet voice to report distant
objects and a loud voice to report near ones, some sort of keyboard
navigation (space flight simulators can be controlled with just the
arrow keys), and a facility for searching for a star by name or type (a
sort of warp drive if you like). I'm not sure exactly how it would work
with a braille display; perhaps something like NetHack maps but with an
added dimension:

http://www.nethack.org/v343/Guidebook.html#_TOCentry_48

A rendition for the young or those with severe cognitive difficulties
might use progressive disclosure, and concentrate on rankings like "the
5 biggest stars", "the 5 weirdest stars" or whatever. Automated agents
could also use the "starmap" to extract similar data.

Now one could certainly argue that this is an extreme example; and that
it is inappropriate to make a simple XHTML table behave in such a way.
Such an argument would depend, however, on a clear and agreed statement
about what XHTML is for, what sort of roles and role interrelationships
may be defined, what sort of behaviour may be added with roles, what
should be reserved for JS or plugins, and so on. Such clarity is still
largely absent from the specification, probably reflecting the lack of
consensus frequently visible on this list.

But even if the "starmap" example were to be dismissed as extravagant,
other simpler semantic roles that require special behaviours (such as
role="culture:spoiler") would likewise be in trouble when it came to
accessifying their semantics.

Sorry to be so long-winded about all that, but I hope it makes what I
was saying a little clearer.

--
Benjamin Hawkes-Lewis

Received on Saturday, 25 November 2006 17:29:19 UTC