- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sat, 25 Nov 2006 17:20:38 +0000
- To: www-html@w3.org
- Cc: "John Foliot - WATS.ca" <foliot@wats.ca>
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