W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2006

Re: User Agent Teleconference for 26 October 2006

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 26 Oct 2006 13:49:06 -0400
Message-ID: <4540F512.1020908@utoronto.ca>
To: Jim Allan <jimallan@tsbvi.edu>
CC: WAU-ua <w3c-wai-ua@w3.org>

Thanks Jim,

My comments inline...

Jim Allan wrote:
>> 9.5 No events on focus change (P2)
>>
>> - this would seem to have AJAX problems - ex. if focus change triggers
>> formatting code that give the control its "has focus" look.
> 
> interesting. In the Note: it says "In this configuration, user agents should
> still apply any stylistic changes (e.g. highlighting) that may occur when
> there is a change in content focus."
> Such as, tabbing to a link changes the focus, and the link text changes to
> bold.
> 
> Are you saying stylistic changes should not be allowed? or is there an
> example where applying a style change is a problem?
> 
> How would this be different in an AJAX control that changes the way it
> appears when it gets focus, but is not activated?

Oops, I think I misread the note on my first pass. You're right that 
this is covered.


>> At the same  time this is tricky because format changes can also change
>> the state of  the control. (e.g. check a check box)
> 
> current functioning in UAs allows users to navigate to (give focus to) a
> form control without causing a change of state. the first radio button in a
> group of radio buttons does not get selected when tabbing between groups,
> although once in a group moving between the radio buttons does cause a
> change of state. Tabbing between (giving focus to) checkboxes does not
> change state. I suppose changing the state of a form control could be an
> event written by an author...
> 
> what am I missing?

Well I was referring to AJAX "entities" that look like "form controls" 
but are not - they are actually Javascript/CSS built objects. The UA 
would not see them as form controls so could give them focus and they 
might activate.


>> - "5.1 No automatic content focus change (P2)" already handles loss of
>> focus that might occur onfocus so maybe point to this in techs.
>>
>> - ATAG handling of this: A success criteria ("The author must have the
>> option to ensure that selection is separate from activation (e.g.,
>> navigating through the items in a dropdown menu without activating any
>> of the items). ") within A.2.1 For the authoring tool user interface,
>> ensure that all functionality is operable via a keyboard or a keyboard
>> interface. [Priority 1]
>> http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060629/WD-ATAG20-2006062
>> 9.html#gl-tool-accessible-operable
>>
>>
>> Cheers,
>> Jan
>>
Received on Thursday, 26 October 2006 17:51:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:34 UTC