W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2010

RE: ACTION-211

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 4 Feb 2010 12:01:02 -0600
To: "'Greg Lowney'" <gcl-0039@access-research.org>, <simon.harper@manchester.ac.uk>
Cc: "'UAWG list'" <w3c-wai-ua@w3.org>
Message-ID: <028001caa5c4$0454f490$0cfeddb0$@edu>
I like the first option, adding some wording to each SC to highlight the
point. Though the 2nd option is fine also and would reduce word in the
document. Don't think we should just drop it. 

Jim

> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
> Behalf Of Greg Lowney
> Sent: Wednesday, February 03, 2010 9:16 PM
> To: simon.harper@manchester.ac.uk
> Cc: UAWG list
> Subject: Re: ACTION-211
> 
> If we think it's worthwhile to encourage UA developers to make such
> view options easily toggled, we have three approaches:
> 
> First, we could put language about easy access to the feature into each
> SC to which it's relevant. The advantage of this approach is it makes
> it really obvious to developers what we expect of them, and for which
> SC.
> 
> For example, something like "3.6.1 Configure Text:  The user can
> globally set the following characteristics of visually rendered text
> content, overriding any specified by the author or user agent defaults,
> AND ENABLE OR DISABLE THIS OPTION WITH NO MORE THAN THREE KEYSTROKES
> (Level A)..." (That's not intended to be final wording.)
> 
> Second, we could have a single SC that applies this additional
> recommendation to those SC where we feel it's appropriate. This SC
> could even enumerate the other SC to which it would apply. The
> advantage of this approach is that it doesn't make the document much
> longer, it doesn't complicate the language of many existing SC, and it
> allows making options "easily toggled" to be lower priority than the
> basic requirement to provide the options (even if inconvenient).
> 
> For example, "x.x.x: the user should be able, using no more than three
> keystrokes, to enable or disable options that change the rendering of
> the page. This specifically applies to x.x.x, x.x.x,..."
> 
> Note that there is precedent for this approach in ISO 9241-171 and ANSI
> 200.2, which have success criteria such as "Software shall allow
> assistive technology to modify keyboard focus and selection attributes
> of user-interface elements, as specified in 8.5.3."
> 
> Third, we could drop the concept of "easily toggled" from the SC and
> only add it as recommended "best practices" in the Implementing
> document.
> 
> Thoughts?
> 
> -------- Original Message  --------
> Subject: ACTION-211
> From: Simon Harper <simon.harper@manchester.ac.uk>
> To: UAWG list <w3c-wai-ua@w3.org>
> Date: 2/3/2010 2:02 AM
> 
> ACTION-211
> Write generic criteria for configurability of UI and content UI
> controls
> (turn on/off, visual presentation, etc)
> 
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JulSep/0018.html
> In reality this action item is missed named, going over the preceding
> discussion we see that it focused on the question of if global
> configurability was required to be within a separate guideline.
> 
> a snip from the discussion shows the intent:
> 
> --
> Show/hide direct keyboard commands are equivalent to show/hide alt
> text,
> etc.
> 
> KP: user needs ability change show/hide link number indicators
> 
> GL: similar to show/hide alternative content. could we have something
> general that covers both
> ... and/or visual indicator of what is a link
> 
> KP: should be more global not a per instance
> ... UA puts numbers by links, but overwrite contents, some users may
> need bigger number or high contrast or translucent
> 
> <Greg> How about something like "the user should be able to easily
> toggle options that change the rendering of the page."
> 
> 
> KP: and be able to quickly turn them on/off
> --
> 
> Looking into the current draft configurability is mentioned all through
> the document, as an overarching principle through the preamble, and
> then
> specifically at many separate guidelines relating to content and UI
> control:
> 
> 3.1.2 3.1.5 alternative text
> 
> 
> 3.5.2 highlighting
> 
> 
> 
> 3.6 text
> 
> 
> 
> 3.7/3.8 synthesyser
> 
> 
> 
> 3.9 style sheet
> 
> 
> 
> 3.12 aternative views and renderings
> 
> 
> 
> also preferences, toolbars, and navigation
> 
> 
> In this case I think we do not need a generic criteria as all aspects
> are very bespoke and any criteria for configuration should be defined
> as
> a guidelines point.
> 
> Cheers
> Si.
> 
> =======================
> 
> Simon Harper
> University of Manchester (UK)
> 
> Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
> 
> My Site: http://hcw.cs.manchester.ac.uk/people/harper/
> 
> My Diary (Web):
> http://hcw.cs.manchester.ac.uk/people/harper/phpicalendar/week.php
> My Diary (Subscribe):
> http://hcw.cs.manchester.ac.uk/diaries/harper/SimonHarper.ics
> 
> 
> ****
> 
> **
> 
> **
> 
> **
> 
> 
Received on Thursday, 4 February 2010 18:02:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 February 2010 18:02:05 GMT