- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 14 Apr 2008 18:03:16 +0100
- To: public-xhtml2@w3.org, w3c-wai-ua@w3.org, wai-xtech@w3.org
disclaimer: i fully realize that simply because the XHTML Access Module is so named, it isn't a document that is intended for accessibility per se, but exists to define a standardized mechanism for anyone to access objects and elements from the keyboard, whatever form that keyboard might take... still, i have a question on the most recent working draft, given the second paragraph of Section 3.1.2. <quote cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/#sec_3.1.2."> Triggering an access key defined in an access element changes focus to the next element in navigation order from the current focus that has one of the the referenced role or id values. Note that it is possible to deliver alternate events via [XMLEVENTS]. It is also possible to have the target element activated through the use of the activate attribute. Finally, it is possible to associate additional event handlers with target which might then perform additional actions once focus is changed. </quote> must activate be boolean? or, rather, can it logically be boolean, given that alternate events may be available through the defined "key", and it is usually the user who knows which event is most suitable for that user's needs... which brings us to the the scenario where a user who wishes to move focus to an element for which an access element has been defined, but who needs to delay the event (if activate="yes") in order to inspect the object with focus for whatever options it might contain... is the assumption that this be where an assistive technology kicks in by responding to an access command by moving focus and then -- through the assistive technology's UI -- provide an exposition of possible actions/options, before the user decides to trigger the event? there is a large population served by accessibility features that do NOT use nor need a dedicated assistive technology, so is it fair to place the onus for activate="inspect" on assistive technology, when, given the possibility of defining multiple events for a single element, such a functionality should be built into the access module itself? it is similar to the trigger concept, endowing activate with an additional safety mechanism -- the ability to half-cock the trigger before deciding whether or not to fire, at which target to fire (in the case of multiple targets/events, or whether to uncock the trigger... gregory. ----------------------------------------------------------- IMPARTIAL, adj. Unable to perceive any promise of personal advantage from espousing either side of a controversy or adopting either of two conflicting opinions. -- Ambrose Bierce, The Devil's Dictionary ----------------------------------------------------------- Gregory J. Rosmaita: oedipus@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ Oedipus' Online Complex: http://my.opera.com/oedipus -----------------------------------------------------------
Received on Monday, 14 April 2008 17:03:51 UTC