Minutes: UAWG telecon 21 June 2012

from: http://www.w3.org/2012/06/21-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference
21 Jun 2012

See also: IRC log http://www.w3.org/2012/06/21-ua-irc
Attendees

Present
    jim, kelly, jan, greg, kim, simon, jeanne
Regrets
    mark, wayne
Chair
    jimallan, kelly ford
Scribe
    kford

Contents

    Topics
        Jan Proposal - Changes to 2.8 Provide toolbar configuration
        3.2 Action-644 - SC on Undo. Proposal from Jan
        SVG images (Greg)
        3.2 Action-644 - SC on Undo. Proposal from Jan
    Summary of Action Items

Summary of Action Items
[NEW] ACTION: JR to With Greg and Kim to bring forward new toolbar SC
wording. [recorded in
http://www.w3.org/2012/06/21-ua-minutes.html#action01]

<trackbot> Date: 21 June 2012

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0123.html
Jan Proposal - Changes to 2.8 Provide toolbar configuration

<Jan> builds on
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0105.html

<scribe> Scribe: kford

JR: reads his definition. Prefaced with not entirely happy but maybe
we can adjust.
... One concern I have is all the things that might be hidden and what
counts as top level functionality. Open, save, bold, these might not
be user agent but what about when you are saving, say as PDF or text.
... When Greg did this he assumed thereJR: My concern with the
previous definiton was that it was too broad.
... I tried to get at the problem by saying we felt it was important
to have fast access to key features that were in nested menus or
functions in general.
... Greg went with the approach if you have tool bars do x. I'm taking
the approach that we want to have toolbars to make commands easier to
get to.

JA: This has become complicated. Goes over where Greg started from and
JR's now means you have to have them.

<Greg> Configurable toolbars have numerous benefits, including but not
limited to: (a) providing quicker (i.e. with fewer actions) access to
commands that are normally hidden or nested; (b) providing pointer
access to commands that normally have only keyboard access; (c)
providing reminders of available options for people with memory
limitations; (d) providing keyboard access for commands that are...

<Greg> ...normally done only with the pointing device (in UI that
doesn't provide menus); (e) providing graphic items for commands that
might otherwise only have text; (f) provide persistent visual display
of information that would normally be hidden or nested (e.g. a
drop-down list box showing font size or name); etc.

JR: Thnis gives you more ability to do whatever you want with your UI
but does demand that you have this one area that's configurable.

JA: Anything that does this?

KP: Word. Kim goes over the Office Quick Access toolbar that allows
you to add almost any command.

<JAllan> can also create unique ribbons with own most used commands or
anything else

JA: I think we now have two separate items. One is now talking about
creating your own toolbars and one talking about being able to
show/hide and such.

<Greg> Should it also address commands that are available through the
keyboard but not through nested menus?

<Greg> One could have it apply to commands available through menu
items or keyboard shortcuts. That would avoid accidentally requiring
every checkbox in dialog boxes to be covered.

Group continuing to talk about toolbar definition. Missed a couple
items in the scribing as they refine.

<Greg> The risk of combining all the existing SC into a single SC is
that, for example, a UA would fail the entirety if it fails to provide
"reset", even if it provides wonderful, fully configurable toolbars.

JA: What confused me was the talk of the nested menus.

JR: What I was saying that if your user interface was so simple that
you have no toolbars, I was trying to say you didn't need them. But if
you had things hidden then you would need toolbars.

GL: Menus in today's GUI environment are all nested then.

KP: What makes the original idea hard????????

<Greg> It's not hard if the app is designed to be scriptable, with
separation of function from UI, but it would be prohibitively
difficult if the app was designed with no abstraction layer.

GL: Word was designed with this idea in mind from the ground up. If
this isn't done, then things are almost impossible.

GL goes over various aspects of toolbars and what we might expect.

This is in reference to fully configurable.

<Greg> Potentially problematic example is if app distinguishes between
status bar where things are displayed vs. toolbar where input takes
place. Would we expect the app to let the user move things between the
two?

JR: There/me anyone else willing to scribe, I'm just not getting it today.
... I think I'm OK with a customizable toolbar as long as you don't
have to have everything. Gives example of not having to have a report
bad web site from Mozilla.

<Greg> Discussion of whether or not configurability is as important as
providing a toolbar at all.

Greg, Jan and Kim agree to work on this area further.
3.2 Action-644 - SC on Undo. Proposal from Jan
SVG images (Greg)

JA: Greg this is one you and I.
... This was on the board from the F2F.
... We have a guideline that says User Agent can do different things
with images e.g. turn them off/on.

<Jan> ACTION: JR to With Greg and Kim to bring forward new toolbar SC
wording. [recorded in
http://www.w3.org/2012/06/21-ua-minutes.html#action01]

<trackbot> Created ACTION-740 - With Greg and Kim to bring forward new
toolbar SC wording. [on Jan Richards - due 2012-06-28].

JA: Question came up with SVG.
... This won't be recognized as an image.
... We then said recognized images?

GL: The question is then for those SC we have on images, should we try
and make them apply to SVG?
... Maybe we need a task to go over all SC to identify which will
apply to non-html items like svg, math ml and such.

<Greg> Perhaps we should make a pass over all the SC identifying which
ones might cause complications with non-HTML formats such as SVG,
MathML, etc.

<Greg> Specifically when SC are written with HTML in mind and it might
not be clear if and how it applies to other web technologies. E.g.
does the requirement to let the user turn off images apply to SVG?

<jeanne> jeanne: I think that's a good idea, but its separate from the
current issue of turning off images.

<jeanne> Kim: in related resources, there is info on 1.2.1 - configure
default rendering addresses this.

GL: We are not able to completely ignore this area.

<JAllan> ack

<Greg> Benefits of being able to turn off images include but are not
limited to: (a) helping users avoid distraction; (b) increasing the
amount of information that can be displayed at one time, including for
people who do not make use of the images due to visual impairments,
people who want to reduce the amount of scrolling, people who need to
keep information on the screen due to short-term memory...

<Greg> ...issues; (c) avoiding pain caused by high visual contrast; etc.

JA: I'm lost. JS has a concern that turning off SVG could turn off
more accessible content.
... The original concern was that we needed to do something about SVG?

Group is going to table this discussion

ack

<Zakim> jeanne, you wanted to say that there are people working on
accessibility of SVG and SVG does have content beyond alt text.
3.2 Action-644 - SC on Undo. Proposal from Jan

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0028.html

<Jan> 3.2.X Text Entry Undo (Minimum): The user can undo text entry
actions that have not undergone content processing. (Level A)

<Jan> Note: Content processing can refer to server-side or client-side
processing.

<Jan> 3.2.Y Settings Change Confirmation: If the user agent provides
mechanisms for changing its user interface settings, then those
mechanisms can reverse the setting changes, or the user agent requires
user confirmation to proceed. (Level A)

<Jan> 3.2.Z Text Entry Undo (Enhanced): The user can undo a sequence
of unprocessed text entry actions by character (or short character
strings). (Level AA)

<Jan> Note: Content processing can refer to server-side or client-side
processing.

JR reads his text.

<Greg> For the first, what is processing? Spell-checking?

<Greg> If spell-checking is a form of processing, then it would negate
the requirement to undo text entry.

JR: This is meant for the rich internet application where user input
is grabbed immediately and the user agent has no idea that this has
happened.
... In those cases the user agent wouldn't be able to undo.

Group talking about example of Googledocs where you can undo.

Group talks further about who process the text and who's responsibility this is.

<Greg> Jan believes Google Docs is a UA, while Kelly believes it is
not; we should come back to that.

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2012AprJun/0059.html

<Jan> The link above is relevant to user agent-authoring tool intersection.

<Greg> Re "3.2.Y Settings Change Confirmation", the SC should allow
the UA to let the user turn off confirmation.

<KimPatch> 3.2.Y Settings Change Confirmation: If the user agent
provides mechanisms for changing its user interface settings, it
either allows the user to reverse the setting changes, or requires
user confirmation to proceed. (Level A)

<KimPatch> 3.2.Y Settings Change Confirmation: If the user agent
provides mechanisms for changing its user interface settings, it
either allows the user to reverse the setting changes, or requires
user confirmation to proceed. The user agent also includes a mechanism
to let the user turn off confirmation. (Level A)

<Greg> What are examples of UI settings that can't be reversed?

<Jan> 3.2.Y Settings Change Confirmation: If the user agent provides
mechanisms for changing its user interface settings, it either allows
the user to reverse the setting changes, or the user can require user
confirmation to proceed. (Level A)

<JAllan> gl: if we can't come up with real examples, then we should remove it.

<JAllan> kim: should keep this. idiot proofing

<Greg> Would for example turning off the option for screen reader
compatibility count as non-reversible, given that the user who relies
on a screen reader would presumably not be able to turn it back on by
themselves?

<JAllan> jr: useful example, but not what I meant. i meant in any way
they user could not reverse the setting

<JAllan> sh: a while ago, I wrote what it means to be a UA, app,
plugin, extensions.

<JAllan> js: all that is in the top of the document.

<jeanne> jeanne: it's in the intro of the Implementing document.

<JAllan> sh: don't want jan to duplicate effort

<JAllan> jr: should have said recognized instead of processed with in 3.2.x,y,z


[End of minutes]

-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 21 June 2012 18:51:03 UTC