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

On Sat, 2006-11-18, David Woolley wrote:
>> I doubt that most of the above elements will ever be important in the
>> HTML that most people experience, which is primarily advertising in
>> nature, nor in the main use within companies, which is as a mechanism
>> for thin client form applications, and these are the real reasons
>> that browsers don't support them.

I wonder aloud if/how you can support these claims.  While much of the
content being created for the web is driven in large part by market forces,
I find it a stretch to presume that this is the only type of content that
consumers (in the small "c" definition) go to the internet for. Just because
the National Enquirer outsells the Wall Street Journal is no reason to stop
publishing the WSJ, or to argue that news stands should stop carrying it -
on the contrary, we should be encouraging those same enablers to support
both papers, and if that is by voting with our feet then get up and get
footing <grin>. 


Meanwhile, Benjamin Hawkes-Lewis wrote:
> 
> This leaves aside the obvious utility of quotation and citation in
> traditional journalism, academia, and law. 
> 

Precisely

> 
> In any case, my main query here is about how user agents are supposed
> to provide access to new roles that their original developers didn't
> know about. Whether such a role is "price", "slider", or "starmap",
> user agents still need to know how it should render and behave.   

While I cannot claim a full understanding of how the current XHTML 2 authors
are envisaging the @role attribute, I have followed it's development as
closely as an outsider can, and they have stated currently that the
mechanism for defining new role(s) is via RDF.

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, for fear that it
will digress to a re-invention of the same problems that accesskey suffers
from today [see: Access + Key Still Equals Accesskey
http://www.wats.ca/show.php?contentid=47]

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.  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.

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

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca

Received on Monday, 20 November 2006 01:31:00 UTC