- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Sat, 4 Jun 2005 12:15:47 -0400
- To: "'Al Gilman'" <Alfred.S.Gilman@IEEE.org>, <www-html@w3.org>
- Cc: <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>
Al Gilman wrote: > Thank you for this beautifully-wrought argument. Much of > this I agree with. > Let me expand on a few points of divergence. Thank you for your kind words. Many long time readers of the WAI-IG list know that this topic borders on religion for me. I too will respond in-line: > > ** summary > > Yes, 'author proposes' is required for hotkey bindings. Fair enough. Propose intent, not action. If it is sufficiently important to declare a hot-spot of "disclaimer", do so. If it is not a 'standard' access role, define it (using RDF?) and provided it an such a way that the user-agent can then auto-discover. But *STILL*, leave the keystroke bindings to the end user, as this person is the only person best suited to define the keystroke required to activate the hot-spot. > This > is needed both > for application-specific hotkeys and for getting the authors > to identify the > hotspots whose access should be accelerated. > > Yes, an element is needed because what is needed is a menu entry and > that needs to be internationalized, including essential > markup such as <ruby>. Pardon if my lack of pure technical expertise emerges... But *why* must it be an element? Why not an attribute? Are not attributes also exposed in the DOM? > > This is not to say we shouldn't be accelerating items based on their > roles. Quite to the contrary. Review the Table of Contents function > in the Mozilla Access Extension being developed in conjunction with > the 'role' work. > > http://lists.w3.org/Archives/Public/wai-xtech/2005May/0011.html Right, and I have looked at this tool. I congratulate Jon Gunderson and his team for interesting and useful work. I will point out that it does *not* bind keystrokes to functionality, yet still manages to expose said functionality (albeit in a "proof of concept" mode). So by concrete example, it has been proven that assigning actual keystroke selectors is not a basic requirement. (As an aside, and not to embarrass Dr. Gunderson or his team, the actual 'homepage' for the Access Extension - http://cita.disability.uiuc.edu/software/mozilla/index.html - can be, in Al Gilman's words, my poster child for why authors should not be able to bind keystrokes. I refer all to the bottom left corner of this page: Accesskeys * A: Announcements * B: Bugs * D: Download and Installation * H: Version History * O: Overview * S: System requirements * T: The Team * U: Documentation * H: Home * O: Software * S: Search <rhetorical> Question: Should "S" then a) focus on 'System Requirements' (item 6)?, b) go to 'Search'(item 11)?, or c) Open my Sage news-reader, yet another Mozilla extension? Or d) go to user settings in IBM's HomePageReader? ) </rhetorical> <massive snip> > > If that functionality has been broken in this draft, we need > to fix it. > > In my theoretical model, the 'access' element is specifying a > pseudonym for the event DOMfocusIn(here) or in other uses > a pseudonym for DOMactivate(here). This is a binding > that belongs in the 'views' layer of the DOM. And since half > the accesskeys are actually intended as pseudonyms for firing > DOMactivate(here) there is not point for a half-replacement > with a dedicated element that only generates the focus > behavior. > > What we need to get across is that we are really annotating > an event with a [menu entry and] hotkey. Not an element. > And since the 'focusIn' and 'activate' events are already > well defined, we don't need any new constructs to create them. So why then did the concept go from being an attribute in Draft 20040722 to being an element in the latest draft? As you have stated, it really isn't an element per-se. >> >> This is, frankly, poppycock. The real question is *why*? By >> preserving this capacity for explicit binding you perpetuate the >> basic problem that exists with the current accesskey - lack of >> standardized keys, pre-claimed and conflicting key bindings for >> various user-agents and adaptive technology, etc., etc. > > There are two 'why' answers that to me validate the requirement > for an "author proposes" part to this "author proposes, user > disposes" key binding. Response in reverse order: > - the other is author interest. If the author is not given > the opportunity > to create a complete user experience, they won't create the semantic > underpinnings, either. ...and if the author is omnipotent then they will be able to completely understand and anticipate all variations of said user-experience. Else they will be hoping for at the very least a general approximation across UI applications. This is nothing new for developers who already conceptually deal with a multitude of browsers/OSes, etc. It is *why* better developers use fluid layouts, separate style from content, use relative sizings instead of fixed, etc. etc. > If we let authors nominate hotkeys, they will > identify the top hot-key-able targets in the page. See, this is where it falls down. You are allowing them to nominate a user-behaviour, and not a document intent (semantic idea). The focus shifted from semantics to behaviours, and this is my complaint in a nutshell. Allowing the author to control behaviours is what is wrong. We decry fixed font sizes (a behaviour), we condemn and deride sites that produce horizontal scrolling (another behaviour), we encourage developers to not launch pop-up windows (a behaviour), and we have a whole raft of guidelines in the WCAG which address other harmful behaviours (auto-refresh, blinking, etc.). Yet we then see a new W3C draft *advocate* controlling yet another behaviour. My arguments may seem simplistic, yet the problem is also very simple. Which of the above "S" functions should work? And why would a spec ever allow this type of problem to exist in the first place? > Else, > not. We need > them identified; we need the carrot to bring the authors to the table. > I believe that asking authors to create intent-based events > without affording > them the means to nominate UI event triggers for them will create > a feature gathering dust on the shelf like the 'link' element in HTML. Here I disagree. Already, smart energetic people and teams are providing "extensions" to a certain browser (see above), other browser manufacturers are committed to evolution and growth, and far from being stagnant this area appears to be once again in flux (IE 7??). With the release of XHTML 2 browser developers will all be scrambling to make their tool *the one* that works best, in pursuit of market share, bragging rights, or whatever else motivates their growth. With a robust, well thought out and easily implemented enhancement, it should be relatively easy to see it embraced. Remember too, that in certain circumstances it will be imposed upon the developers (witness the "UK Standard") - the 'stick' to your carrot. 5 or 6 years ago, a band of "we're not going to take it anymore" web developers formed a group called WaSP, and very quickly we saw CSS 'standardization' and compliance (sic) emerge. I am not worried that if this is/was done right that there would be a real difficulty in getting developer buy-in. > > - one is application-specific verbs. My posterkids for these are some > of the actions in a web-ified email archive or WebMail ap. > These would > include "next message in thread" or "this message in threaded index > view." Waiting for standard terms for these is a losing > play. Which is why allowing the 'roles' to be defined via RDF makes sense. > > So, there is sufficient reason to let the author propose something. Agreed, propose intent, not action. > > The flip side is also true: removing the author's ability to nominate > keys will not achieve the standard UI names that you would prefer. > That is a topic of balance-of-terror detente among the OS vendors. > JTC1 SC35 is trying to do that and like ISO HTML, it will be roundly > ignored in the real world. The place where we can have a reasonable > expectation of uptake in the commercial Web is at one remove from the > user experience, in naming the intent-based events. I'm not sure exactly what you are getting at here... > >> I like "Role", I like the pre-determined list of common roles and >> the fact that role is extensible via RDF. Leave it there. Let the >> users determine the how and what. Never mind letting the author >> "guess" which key is most appropriate. I honestly thought that we >> had gotten past "look" as a criteria, leaving that to CSS. > > CSS needs semantic info in the 'content rep' to key when to do what. > If the hotkey is specified in a CSS rule with a #id selector, then > the CSS is not style, it is holding content hidden from the AT > cruising the DOM through the access API. ??? Intent, semantics, and functionality are not style issues. I never for once suggested that this type of function be relegated to CSS. Perhaps I am naive or ignorant, but here's my conceptual idea: A) W3C has a 'standard' list of common roles (as per Draft 20050505) B) Custom 'roles' are defined via RDF C) "Access" becomes simply a meta element (akin to link) so that when defining custom 'roles' it can be auto-discovered by user-agents. This type of function already exists in "auto-discovery" RSS feeds. <access role="disclaimer" rdf.resource="">. Admittedly, this is the weakest link in my proposal, however I do not think this outside the realm of possibility. D) "Role", as an attribute, becomes the intent declaration. Like other attributes (lang, title, class, etc.) role can then be applied to any semantic construct: <p role="disclaimer">. Good UI's will then "announce" when a custom role is present and allow the user to bind (or ignore) on a case-by-case basis. (perhaps the "title" attribute would also be required to give the role a human readable identifier?) E) Binding is left to individual user-agents / user preferences. This does not preclude any user-agent from providing a "default" key binding within their UI to the list of 'standard' roles defined and published by the W3C. I will point specifically to Opera as a tool that demonstrates this type of function, allows this, and allows end users-to re-map via the UI directly (not by fiddling with alternate style sheets, userJS, or other arcane, "geeky" methods). As has already been pointed out, this is not realistic either. The net effect here is that, by and large, those developers that you are seeking to "carrot" get their functionality without having to "guess" at appropriate keystrokes, the majority of end-users have a stable, learnable, reliable and CONSISTENT method of invoking keyboard navigation, yet customization of key-bindings is left directly with the end user if and when required. The content author never had a say in it. ...*and* not yet brought to the table is the idea of internationalization... What happens when "S" is not on Mr. Zhang's keyboard? If the intent is declared, then any key (not the "S" key) can be mapped - further extensibility. I am prepared to have holes punched through this, please. > > You're lost in some theoretical world if you don't admit that web > developers *must* optimize the look and feel of their web aps to stay > in business. Sir, as a long-time web accessibility evangelist, I have heard this argument for more than 5 years now. I am not lost in the clouds; I like and appreciate well designed, "pretty" web development. As a small indie shop, I "get" that all too well, as this is the point of view *all* of my small business client base understands. But I also understand user frustration, as this same client base I work with generally tends to be of the "casual" user variety. Revisit the example I pointed out above, with the Web Accessibility Extension page. As a casual user, which "S" function would *you* expect to work, and if it didn't how would you feel? As I proudly claim on my personal site, The Web Is Not TV! To have this kind of thinking suggested at the W3C is frustrating to me. > > We *must* preserve the adjustability of that look and feel. But we > will simply fail if we try to do anything less than facilitating that > optimization by the content developers. Optimize, yes. Control, no. > > > Sir, you're dealing with two working groups, here. With due respect, I am dealing with the W3C - arbitrators, and controllers of the final spec. > > The latest draft XHTML 2.0 has been developed by the HTML WG. > > The idea that the XForms language is "good enough" in terms of > assuring access is a matter that was consensus in the PF WG the > last time it came up for consensus. > > The current draft was supposed to be a Last Call draft, that the > HTML WG considered 'done.' It is not. Not even the HTML WG > thinks that they have got every detail right in this draft. So > bear with us, it is a work in progress. <snip> > > Thank you for your persistence in trying to keep us honest. Just trying to do my part to keep the web accessible for all. "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee, W3C Director and inventor of the World Wide Web JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053
Received on Saturday, 4 June 2005 16:16:12 UTC