See also: IRC log
<trackbot> Date: 04 October 2012
<JAllan> rrsagent make minutes
<KimPatch> Jeanne: distribute document widely -- tweet, distribute
<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.
<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
... 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
<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
<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.
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
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: 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?
... 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> 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
... 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
... 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
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
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
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
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Jan: we/Greg: we/ Succeeded: s/level A -- stays level A/level A -- Undecided...more discussion needed/ Found Scribe: jeanne Inferring ScribeNick: jeanne Found Scribe: KimPatch Inferring ScribeNick: KimPatch Scribes: jeanne, KimPatch ScribeNicks: jeanne, KimPatch Default Present: Jeanne, Greg_Lowney, Jim_Allan, MarkHakkinen, Kim_Patch, Jan Present: Jeanne Greg_Lowney Jim_Allan MarkHakkinen Kim_Patch Jan Regrets: kelly Found Date: 04 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/04-ua-minutes.html People with action items: markku WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]