- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Thu, 14 Oct 2010 10:06:24 -0800
- To: Jim Allan <jimallan@tsbvi.edu>
- CC: WAI-UA list <w3c-wai-ua@w3.org>
- Message-ID: <4CB746A0.4000307@access-research.org>
That makes perfect sense, but the term "input focus" could be replaced with something clearer, especially since the outlines are not solely associated with keyboard focus. Some potential wordings: * "outline (with configurable color and width)", or * "outline (with configurable color and width, e.g. the CSS outline attribute)", or * "outline (with configurable width and color, including inversion)" Interestingly, CSS does not define precedence, but I think it would make most sense for outlines associated with keyboard focus to take precedence over outlines associated with element types. For example, one might want to have enabled elements have a pink outline to make them easier to spot, but the element with the keyboard focus have a yellow outline to make it *really* stand out as it moves around. In that case, the yellow outline should override (or overwrite) any pink outline on the same element. We could consider adding an SC to that effect. I find it odd that CSS outline does not address outline animation, a classic part of the "marching ants" selection indicator. Greg -------- Original Message -------- Subject: Re: Problems with 3.5.2 From: Jim Allan <jimallan@tsbvi.edu> To: Greg Lowney <gcl-0039@access-research.org> Cc: WAI-UA list <w3c-wai-ua@w3.org> Date: 10/12/2010 1:04 PM > Greg, > I like the first option of combining the two check points. It is much > cleaner. The 'input focus' was intended to apply to the 'outline' css > property that puts the 'ant-trail' around anchors that have focus, and > will be activated when the user hits enter. The latest versions of UAs > implemented the 'outline' selector in css, and authors immediately > jumped on it, set it to 0 to eliminate the ant-trail. Users should > have an easy way to reinstate/configure the 'outline' selector without > having to write a user css. With all that said, is 'input focus' an > appropriate term? > > Jim > > On Thu, Oct 7, 2010 at 1:10 PM, Greg Lowney > <gcl-0039@access-research.org> wrote: >> Hi, >> >> Here are a few problems with 3.5.2 that I noticed. 3.5.1 and 3.5.2 currently >> read: >> >> 3.5.1 Highlighted items: The user has the option to highlight the following >> classes of information so that each is uniquely distinguished. (Level A): >> >> (a) selection, >> (b) content focus, >> (c) recognized enabled elements, and >> (d) recently visited links. >> >> 3.5.2 Highlighting options: The highlighting options (with the same >> configurable range as the operating environment's conventional selection >> utilities) include at least (Level A): >> >> (a) foreground colors, >> (b) background colors, and >> (c) input focus (with configurable color and width). >> >> 1. In the SC 3.5.2 item C, the term "input focus" is incorrect; the Intent >> paragraph and example both discuss borders, which would make more sense and >> better fit the listed properties of "color and width", so list item (c) >> could be changed from "input focus (with configurable color and width)" to >> "border color and width". However, what software actually provides an >> optional, adjustable border for selection, content focus, enabled elements, >> visited links, etc. for both user agent user interface and rendered content? >> ("Text cursor" also has both color and width, but wouldn't really apply to >> most of the things to be highlighted.) >> >> 2. 3.5.2 only makes sense if you know it's supposed to be applied to 3.5.1. >> They could either be merged (as I seem to recall us discussing doing for >> another pair of closely related SC) or modified to refer to each other. The >> arguments for combining them would be that they're intimately tied, that as >> both are Level A to conform you have to do both anyway, and that it could >> simplify the wording if 3.5.2 doesn't have to refer back to 3.5.1; the >> arguments against are that you might want to check them off separately to >> keep track of partial progress towards full compliance, and to avoid having >> one success criterion with two lists. >> >> The first approach is combine them: >> >> 3.5.1 Highlighted items: The user has the option to highlight the following >> classes of information so that each is uniquely distinguished: >> >> (a) selection, >> (b) content focus, >> (c) recognized enabled elements, and >> (d) recently visited links. >> >> The highlighting options (with the same configurable range as the operating >> environment's conventional selection utilities) include at least (Level A): >> >> (a) foreground colors, >> (b) background colors, and >> (c) input focus (with configurable color and width). >> >> The second approach is to modify 3.5.2 to explicitly refer to 3.5.1 so you >> know what it's about, such as changing the beginning of 3.5.2 to read "When >> complying with 3.5.1, the highlighting options...", thus yielding: >> >> 3.5.1 Highlighted items: The user has the option to highlight the following >> classes of information so that each is uniquely distinguished. (Level A): >> >> (a) selection, >> (b) content focus, >> (c) recognized enabled elements, and >> (d) recently visited links. >> >> 3.5.2 Highlighting options: When complying with 3.5.1, the highlighting >> options (with the same configurable range as the operating environment's >> conventional selection utilities) include at least (Level A): >> >> (a) foreground colors, >> (b) background colors, and >> (c) input focus (with configurable color and width). >> >> Thanks, >> Greg >> > >
Received on Thursday, 14 October 2010 17:08:18 UTC