User Agent Accessibility Guidelines Working Group Teleconference -- 04 Oct 2012

<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

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

04 Oct 2012

Attendees

Contents

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

Scribe.perl diagnostic output