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

minutes: UAWG 4 Oct 2012

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 4 Oct 2012 13:37:20 -0500
Message-ID: <CA+=z1WnA-wGcpFr9XxUPm_B_CHd_-4Dg1WYxXnR6PxvCtVFqLw@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from: http://www.w3.org/2012/10/04-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
04 Oct 2012

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

Present
    Jeanne, Greg_Lowney, Jim_Allan, MarkHakkinen, Kim_Patch, Jan
Regrets
    kelly
Chair
    jimAllan, KellyFord
Scribe
    jeanne, KimPatch

Contents

    Topics
        Volunteers writing mobile examples
        review 1.6.2 Speech Pitch and Range
        Levels Discussion
        Privacy UA Community Group http://www.w3.org/community/pua/
        Levels Discussion
    Summary of Action Items

<trackbot> Date: 04 October 2012

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0070.html

<JAllan> rrsagent make minutes

<KimPatch> Jeanne: distribute document widely -- tweet, distribute
Volunteers writing mobile examples

<jeanne> scribe: jeanne

KP: At the Boston Unconference I said to Judy that it would be good if
we had more mobile examples in UAAG. She dragged me into a mobile
accessibility session and got 6 volunteers to write examples. Most of
them are in Boston, and the ones that aren't in Boston will be
traveling to Boston.

JS: And this group are also invited to attend.

KP: All day Friday the 12th, at MIT.

JS: There will be a zakim dial-in number, I will send it out when I get it.

KP: we will go through the document, explain the format: here is the
person with this disability. We won't do wordsmithing, just move fast
to get the examples.

JA: It will be a good review from people who have never laid eyes on it.

KP: We will note other comments, but stay focused on the mobile examples.
review 1.6.2 Speech Pitch and Range

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0070.html

<KimPatch> Jim: added a few words and the note to 1.6.2

<JAllan> new 1.6.2 Speech Pitch and Range: If synthesized speech is
produced, the user can specify the following if offered by the speech
synthesizer:

<JAllan> old 1.6.2 Speech Pitch and Range: If synthesized speech is
produced, the user can specify the following:

<KimPatch> Note: Because the technical implementations of text to
speech engines vary (e.g., formant-based synthesis or concatenative
synthesis), a specific engine may not support varying pitch or pitch
range. A user agent will expose the availability of pitch and pitch
range control if the currently selected or installed text to speech
engine offers this capability.

<Greg> What if a user agent bundles one or more speech synthesis
modules; is there no incentive for them to include one that does
support pitch and pitch range?

<JAllan> scribe: KimPatch

Mark: if it's in the engine it's exposed, if it's not, greyed out

Greg: we don't want to get into the chicken and egg problem where
there's no incentive on the user agent to require those functions --
they're not required to request or select one that has it

Mark: some of the ones that are preferred by our test subjects don't
have those capabilities
... higher-quality engines really purely modeled after real speech samples
... there are users that prefer certain speech engines because they
want that feature -- there are speech engines that don't -- if
supported it's incumbent on the user agent pass that along

discussing history
Levels Discussion

<JAllan> ACTION: Markku to take over rewrite of 2.8 [recorded in
http://www.w3.org/2012/10/04-ua-minutes.html#action01]

<trackbot> Created ACTION-763 - Take over rewrite of 2.8 [on Markku
Hakkinen - due 2012-10-11].

Jim: going through -- not rewording, just saying whether it goes up or
down, starting at 1.8.3
Privacy UA Community Group http://www.w3.org/community/pua/

<jeanne> This came out of last week's CG meeting: MC: This came from
PF regular review of community groups. This

<jeanne> group wants to write use cases for privacy for user agents. We

<jeanne> want to make sure that they know our use cases, such as

<jeanne> fingerprinting based on assitive technologies.

<jeanne> ... I was hoping UAAG will take it.

<jeanne> KF: I will bring it to the group and ask for a volunteer.

Jeanne: good opportunity to make sure accessibility is included,
hoping that someone in UAAG will be able to take a look and make sure
that there are accessibility use cases
... community group, they've taken on writing use cases for privacy in
user agents -- like do not track so people understand what they are
choosing when they choose these options

Mark: usability sessions that migrate from browser to browser session
and make sure they don't filter out of the user control

<JAllan> The Private User Agent (PUA) Community Group is chartered to
address covert sharing of User Agent (UA) state and to improve the
security of the UA in this regard. The group seeks to standardize the
designs necessary to achieve these goals, to develop extensions
designed to mitigate inevitable losses of functionality, and to
discuss and develop implementations and test suits. Mechanisms for...

<JAllan> ...expressing user privacy preferences to servers and content
provides are outside the scope of this group.

<JAllan> http://www.w3.org/community/pua/wiki/Draft

Jan: you can sniff for users with disabilities -- you can also sniff
on the server side for all kinds of things -- reaction time or if they
click on invisible buttons...

Jim: I don't see any use cases on the site now -- they're still really new
Levels Discussion

1.8.3

level A -- Undecided...more discussion needed

Jan: viewport includes edit fields, might include scrolling Diivs, a
think this is not an A

Jim: what's our definition of viewport

<Jan> from Glossary: viewport: The part of an onscreen view that the
user agent is currently presenting onscreen to the user, such that the
user can attend to any part of it without further action (e.g.
scrolling). There may be multiple viewports on to the same view (e.g.
when a split-screen is used to present the top and bottom of a
document simultaneously) and viewports may be nested (e.g. a...

<Jan> ...scrolling frame located within a larger document). When the
viewport is smaller in extent than the content it is presenting, user
agents typically provide mechanisms to bring the occluded content into
the viewport (e.g., scrollbars).

Greg: viewport includes the top-level window, some controversy for
what included. Some browsers, chrome you can resize pretty much
everything you can grab, they seem like they fall into our definition
of viewport

<Jan> JR: I'm thinking AA

Greg: my general feeling is that sometimes it's useful to distinguish
between different kinds of viewports. Jan was referring to top-level
viewport full-screen, if you can't resize that window that make you
fail? The other difficult case is -- I don't know anybody who supports
manual resizing of single line edit fields

Jan: can chrome resize divs?

<Jan> http://www.domedia.org/oveklykken/css-div-scroll.php

Jan: I don't see any way to

Jim: no arrow grabbers

Greg: my concern is this -- is there any user agent that would pass if
this was AA -- not if we define it this broadly. We could split this
into a couple different requirements some of which are narrower. For
example resizing a multiline input field like a text box -- and some
browsers would pass, so we would be encouraging that

Jan: what browser can resize a multiline text input?

Greg: Chrome?
... one of the browsers puts a resize handle at the lower left of
every multiline input box

Mark: that's a user agent widget -- I've seen that in chrome, maybe Safari
... it's an input field -- they're form controls, not divs

<Jan> example: http://www.w3schools.com/html/showit.asp?filename=tryhtml_textarea

<Jan> Chrome does allow me to resize

<Jan> So does FF15

Greg: if some people do it for certain things that we could do a
double A requirement for multi- line edit controls

Jan: Safari does it on a Mac
... it doesn't stretch the whole size of the display, it makes the div
ithat it's living within scrollable

Greg: the containing viewport

Jim: it's only a bottom resize

Jan: what's the keyboard accessibility of that?

<Jan> Interesting: http://www.askthecssguy.com/examples/scrollingbox/index.html

<Jan> So supported in form control but not when its a div

<Greg> Rresizable multiline edit fields could be AA, resize top-level
windows on platforms that support it could be A, but resize all
viewports is probably beyond our scope because not implemented by any
browser today.

<Greg> Ideally of course what can be done to multiline edit controls
would also be for list boxes, including drop-down list boxes.

Jim: based on what Greg is saying 1.8.3 will either be a AAA or goes
away or we rewrite it into two or three with the incumbent examples
and intent and all that

Greg: leaning toward the latter
... even if most browsers supported resizing multiline edit Fields I
don't see it as a because the impact of lacking it isn't strong enough
whereas not being able to resize a top-level window can be worse
because in many cases those don't support scrolling and making text
bigger makes things disappear

Jim: just reading this we assume you're trying to make the window
bigger -- I've seen what Greg was describing where you have someone do
that opens and your font is too big and things disappear and there's
no scrollbars, so if we change this to can resize top-level graphical
viewports -- change the type of graphical viewport were talking about

Greg: a multilevel viewport is not a top-level window

Jan: the bigger thing here -- why do you want to resize the viewport
or edit field -- because these things have scrollbars and you want to
see more of what's behind there without so much using the scrollbar,
whether it's an edit field or the whole window
... and then we have this practical constraint that view ports within
viewports within viewports -- what if we say something like -- if you
port that isn't able to show the full content resize to the limit of
the display or the limits of its own containing viewport
... we could say recognized scrollbars, and that would get us out of
weasley situations where the user has put in scrollbars that the user
agent doesn't know anything about

Greg: I'd like to look over some stuff before we finalize a decision
on new wording.

looking at related action items

1.8.3 undecided

Greg to look rewording and send to list

Greg: 1.8.3, 1.8.4 and 1.8.11 are all related

Greg to look at all three

<JAllan> 1.8.4 - subject to change pending Greg submission

<JAllan> 1.8.11 - subject to change pending Greg submission

1.8.5 -- currently level A

Greg: should be general enough to let people recognize other
mechanisms not just scrollbars
... for example Google maps is essentially an infinite scrollable area
so scrollbars wouldn't make sense
... current wording is unclear as to extent -- if an application uses
scrollbar but doesn't indicate whether you are 90 percent or 10
percent -- do we want to rewrite and include extent

Jan: position is enough -- extent is easier to figure out
... we should change "to the full extent" to "to the full recognized extent"
... so if I'm streaming in a video it may be the case that the
position is given to the user agent but it may be that it is not

Greg: fixed width only gives you are you at the bottom or are you at
the top, no other information -- is that sufficient?

Jan: are screeners able to access that information?

Greg: standard scrollbars, but if not standard scrollbars
... menus that are built into the user agent would not

<jeanne> http://www.w3.org/2012/09/20-ua-irc

<JAllan> http://www.w3.org/2012/09/20-ua-minutes.html

looking at log from the 20th -- 2.3.2 is the next one

<JAllan> 2.3.2 Present Direct Commands in Rendered Content

<JAllan> Jan: don't think its A, folks learn this

Jim: if they're visible you can look at it -- if it's not on the
screen then you're going to have to remember or tab to get around it

<JAllan> kim: right they don't learn, these need to be visible so
people can remember and use them

Greg: undecided -- I think it's a valuable thing. a lot of web
browsers don't do built-in, but get extensions to do it

Mark: I'm a thing at different tablet-based browsers that were
experimenting with -- I see a lot of creativity in how things such as
scrolling appear and whether they are even visible at all until you
start to do something. I'd like to get the user agents to make it
obvious that you can do these things.

Greg: I wonder if we ensure that user agents include the ability to
see the access keys will that help us promote the use of access keys?

Kim: yes -- discoverability is everything

Greg: do we know who would pass today?

Jan: it's not just access key, if anything were a direct command of
the keyboard is going to do something on the screen, and present the
command with the related element -- I don't think Jaws does that

Jim: I can get lists, but it doesn't expose them in the content as you go along

Mark: there's no way you're going to expect the user agent to parse
the JavaScript

Jan: that's why recognized
... what does Lundmark apply here -- on the navigation bar roll what
will you have? What would that look like?
... direct commands -- were talking keystrokes -- direct commands that
either take you to a spot on the page or activate something. Example,
something has a little h on it, is that the idea?

<JAllan> kim: cognitive issues, if you don't know the keys you can't push them.

Jim: we will continue with 2.3.4 next week

<jeanne> MC, can you assign a keyboard shortcut to an ARIA landmark?

<jeanne> that's outside the ARIA spec

<jeanne> ... the UA could provide such a feature if it wanted

<jeanne> ... or the author could, as a separate step from providing the role

<jeanne> ... but there's no requirement

<JAllan> could put an AccessKey in the same element as a landmark and
use that for navigation to the landmark
Summary of Action Items
[NEW] ACTION: Markku to take over rewrite of 2.8 [recorded in
http://www.w3.org/2012/10/04-ua-minutes.html#action01]

[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, 4 October 2012 18:37:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 October 2012 18:37:47 GMT