- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Wed, 7 Dec 2005 20:35:43 -0500
- To: "'Steven Pemberton'" <steven.pemberton@cwi.nl>, <w3c-html-wg@w3.org>, "'W3C HTML Editors'" <www-html-editor@w3.org>
- Cc: <wai-xtech@w3.org>
Steven Pemberton wrote: > John, > > Thanks for your (long!) comment. And thank you for your response - which I will presume to be an informal response as opposed to a formal one on behalf of the XHTML Editors. My comments follow: > > First let me say that XHTML2 is being designed with direct contact > with > the accessibility groups at W3C and Richard Schwerdtfeger is on the > HTML > WG himself. > Yes, and I am also in discussion with Al Gilman on this subject, amongst others. > Let me try to address your points one by one. > > It is not an aim to get rid of all behavioural markup in the > language. On the contrary, where there are clear needs identified by > current use of scripting (in HTML4/XHTML1), then we have introduced > declarative markup to cover that case. Navigation lists are a good > example of this. While this is true, you leave the actual rendering of the list (and any other "functionality") to the individual user agents and or DOM scripting, as not all UA's will deal with <nl> in *exactly* the same manner. This is one of the fundamentals of my argument - you read my Mantra: Declare the intent and leave the binding assignment to the end user. This is also consistent with the earliest "rules" of HTML, where the semantic meaning is "marked up" but final rendering is decided upon by the end user agent. My GUI browsers generally (not exactly) render <h1> as large text (when unstyled), whereas my Lynx browser deals with <h1> in a completely different way - yet the meaning is consistently conveyed in all of these browsers. This is HTML 1.01 > > We did indeed attempt a solution to the requirements we had to that > used a DOM-based declarative markup, but with the lack of sufficient > architectural support, we fell back to the current design. > Given that no user agents currently supports XHTML 2 anyway, is this not a weak argument? I am unaware of anything that can currently parse the proposed RDF declarations for custom @roles as proposed, yet that does not preclude you adding this to the Spec. > > There are two communities who have expressed to us a need for > author-supplied key bindings, and with which we have had discussions. > One is the accessibility community, To which I am most certainly a vocal and recognized member, and I have already garnered some support for my perspective, from both developers and end users via a number of discussion lists. Please do not confuse the opinions of a few as being representative of the entire community - those that speak on behalf of the Accessibility community at the W3C, while commended (and to which I have both much respect and admiration), were never *elected* or otherwise appointed to speak for all. The jury is still most certainly still out on this matter - suffice to say there are dissenting voices on the topic. > the other is the mobile > community. There is also a third, the HTML community, who want to be > able to continue to do what they do in existing versions of the > language. Except, more often than not, the HTML community are not using ACCESSKEY, due to the inherent problems with it. I have been talking and cajoling and generally seeking to teach on this subject for over 3 years now, and even a perfunctory search on any major Search Engine for "accesskeys" will quickly point to either one of my articles or a site that subsequently points to one of them. My simple little chart that details known key stroke conflicts is referenced, on average, 1000 - 1500 page views per month, and has been almost since the date it was published. I can safely say that the tide of developers who do not use accesskey (either through ignorance or due to the evangelism of myself and others) is far greater than those that cling to them. For the most part, the only sites that continue to perpetuate ACCESSKEY are those that are mandated to (i.e.: UK "standard") > > I think that the community that uses it the most is the mobile > community for binding keys (0-9*#) to menu entries. > <snip> > > However, in non-accessibility > environments, such as in mobile use, there is still a perceived need > to be able to specify a key. But that perception is wrong - and it should be the W3C that helps them to see this! This community, more than any other, must/should know that attempting to bind something to an alpha key will not work on their devices - yet they claim that authors should be able to do it? What is wrong with this picture? Can anyone honestly say that they anticipate sophisticated "web applications" (which, BTW, should more honestly be referred to as web APIs, as the actual application is the User Agent, which interacts with the authored materials) will be accessed via mobile devices (telephones?) An honest response, please. The mobile community, more than any other, stands to benefit the most by specifically NOT allowing authors to bind functions (et al) to specific keys, as this community has far fewer keys to work with than standard keyboards. By removing the ability for an author to bind a specific to an alpha key, the @role declaration is left open to the user agent to access, un-encumbered. The Draft Recommendation intends to define Common Roles, and in fact has already started to do so. The manufacturers of these devices must surely wish that a standardized list exists, so that they could then universally map to them with their limited keystroke combinations. This then raises an interesting point: Since the W3C is already defining a Common Collection of ROLES, why not also, as part of the XHTML 2 specifications, specifically map these same Common Roles to specific numeric keys? You know the answer as well as I - yet if an authorative body such as W3C cannot state a universal set of bound keys to even the Common Role Collection, what leaves anyone to believe that individual authors can do a better job? However, if we leave that job to the proper actor (the user agent), then who cares? My Nokia phone binds "Privacy" (which, BTW, should be a Common Role item) to "#9", Kyocera uses "*4", JAWs uses "Alt+Z" - whatever works for each user agent. Why are you going to let some yahoo in Kalamazoo bind it to "Alt+F"? At this point, with the proposed draft solution, we now require these same devices to intercept, re-map or otherwise react and over-ride Kalamazoo Kevin's bindings? This is intelligent design? > >> MANTRA: Declare the intent and leave the binding assignment to the >> end user. > > A good tenet, but not a reason in itself for disallowing explicit > bindings. Perhaps, but I have not even heard a supportable reason for *allowing* explicit bindings, save for a "perception" which can easily be de-bunked. >> Technical Reports: [T] - In most mainstream browsers, this is >> supposed to open the "Tools" dialogue, in HomePageReader it is the >> shortcut for Table Navigation, and in the laptop configuration for >> JAWS, it is supposed to "Speak the Title of the Current Window" - >> except at the W3C site of course (Oops again...) > > I don't understand why this is this a bug in HTML4 or W3C, and not in > Jaws. I would complain to Jaws personally. Althought the HTML4 spec > doesn't disallow using the same key combinations as the chrome, it > doesn't require it either; it seems like a bad choice for a browser > to use it. Please re-read that. This is not a "bug" in one user agent ), but a conflict in ALL user agents that I have tested. For shame! (And for the record, JAWS is not a browser/user agent at all, but rather an essential Adaptive Technology application used by the visually impaired, which interacts with other applications on the Windows Platform). At best it is a shared guilt - the user agents for not providing appropriate conflict resolution, and the author and authoring language that allows such conflicts to exist. At least with JAWS, it *does* over-ride the user-agent, but unfortunately not the author supplied binding (perhaps because they are so rare?) The very simple fact is for Adaptive Technology users, they *MUST* use key stroke navigation, as pointing devices are simply a non-starter. For most blind or visually impaired users, the "ALT+T" keystroke is a reliable and learned action which *should* (read MUST) produce a standardized result; you will note that the 2 referenced A.T. solutions use ALT+T differently, yet for those unique users, it should be a consistent result *regardless* of the web site they are on. That any given author can over-ride this today is criminal, doubly so that it is the W3C. To argue that this is a flaw of JAWS (never mind IBM's HomePageReader plus all of the major user agents) strikes real fear (and sadness) into me, as it clearly illustrates a complete lack of understanding of the issue at hand. I do not say that to be insulting, honestly I do not, but please... This is clearly an author error - plain and simple, as on the majority of web sites this is not a problem - it is only broken at the W3C because the author added it to their source code. This is why they should not be allowed to do so! >> User settings over-ride all user-agent mappings and author declared >> bindings. (Highest Priority) User-agent mappings over-ride author >> declared mappings. (Second Highest Priority) Author declared >> mappings be exposed/honored. (Lowest Priority) >> >> While this is still a less-than-perfect solution to me, I believe it >> to be an acceptable compromise to address some of the concerns >> raised. > > Good. However, if this is truly the case, why would any author ever want to apply a key-binding? In most if not all instances it will be over-ridden, and this may in fact cause the opposite effect - authors will simply not bother with access because "...it doesn't work" (<cite> anyone?). This does a great dis-service to the community that most require advanced key-board navigation - the Accessibility Community. To re-quote the preamble to the XHTML 2 Draft Recommendation, is not the intent to create "...a common framework that allows data to be shared and reused across application, enterprise, and community boundaries...to create a general-purpose markup language...[that] does not attempt to be all things to all people..." If this is truly the case, then there is no need for key-binding: this is (rightly) the current and future responsibility of the end user and their user agents. > > > Please send us your design. Since there are communities that would > not be happy if we removed @key, we will not do so, but if you can > come up with something that you consider a better design, we'd be > happy to see it. I outlined a scenario in my original posting. It moves the hinting to the RDF declaration, where it belongs. User agents that can extract useful information from this same said RDF file will be able to provide a hint to the user agent, to then be acted upon by the end user - with one of the end user's very real options to simply ignore the hint. Your scenario has the user agent being told what the key-binding is, and then forces the end user to modify author supplied instructions - which would seem to me to require more overhead on the part of the end user/user-agent (has the mobile community thought about that?). One gives the choice to the user (mine) the other to the author (yours). This is wrong. Finally, there will always be communities not happy to see something go - yet I do not see <marquee> or <blink> in the XHTML 2 draft (said half joking, half seriously - sadly the written word lacks any ability to convey body language or subtlety). Thank you for your time. Sincerely, John Foliot > > Best wishes, > > Steven Pemberton > For the HTML Working Group
Received on Thursday, 8 December 2005 01:36:12 UTC