See also: IRC log
<trackbot> Date: 27 May 2010
<kford> /me man a week away and you forget stuff.
<AllanJ> chair: JimAllan
Jim reports that James Craig of Apple will not be able to participate as much as he would like to, so has withdrawn from the working group.
However he will respond to email if we have specific questions.
<AllanJ> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/
Jim reports the HTML5 working group is preparing a survey on media requirements (link above).
Jim gave them UAAG's requirements that should be incorporated into their proposal. It includes structured and hierarchical navigation, which Janina was concerned should be included along the lines of DAISY. Mark had sent her material on DAISY navigation.
Anyone on the HTML accessibility task force list will can participate in the survey; otherwise can forward comments to those on our WG who are members.
Jim sent the list a pointer to a document on keyboard input model for navigating rich controls.
<AllanJ> https://wiki.mozilla.org/Accessibility/RichContentKeyboardBehaviour).
<AllanJ> https://wiki.mozilla.org/Accessibility/EditorBehaviourOnUserInput
It appears to be only focused on screen reader users, and not addressing people who don't use assistive technology.
<AllanJ> wai-xtech@w3.org
wai-xtech@w3.org is the public part of the PDF working group, where PFWG does a lot of their public discussions such as this keyboard navigation model.
Jim suggests when sending comments to xtech, cc uawg.
<AllanJ> viewmode http://www.w3.org/TR/2010/WD-view-mode-20100420/
The viewmode discussion is part of their candidate recommendation and comments are already closed, but it was brought to our attention this week.
Jim notes some issues are transparency setting and ability to omit chrome from windows.
Jim would like at least a few people to review it, but they require comments by today! *Very* little notice or time to review.
Jim, having at least looked it over, will send some broad comments.
Greg suggests we may need to revise our guidelines so that we don't need to updated them every time user agents add a new window or content attribute; rather, we could have a few very broad success criteria that basically say the user must be able to override ALL window and content attributes, and then transparency, chrome, etc. would be examples.
<AllanJ> Greg says we need to be granular and broad, with examples.
Kelly would prefer to err on the side of being too specific, rather than too general, or else we might miss too much.
Kim agrees we need both approaches.
<AllanJ> +1
Jeanne says it makes documents easier to read if they start more general before getting into details.
Kim requests comments on the position paper she sent around, from the working group on conversational applications.
<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010AprJun/0064.html
Kim is trying to get across the message that thinking about usability for people with limitations increases usability for everyone.
Kim will be spending two days at that group's meeting.
Greg asks if anyone else is reviewing the 508 refresh proposal.
Jeanne, Mark, and Greg have done so. Jeanne's comments were submitted as a block from WAI.
<AllanJ> http://www.w3.org/2002/09/wbs/36791/20100521/results
Re 4.7.x (Location in Hierarchy), Simon intends to do a rewrite.
<AllanJ> 3.10 .5 http://www.w3.org/2002/09/wbs/36791/20100521/results#xq7
Mark notes that user agents seem pretty good at determining when scroll bars are needed.
Greg
Greg's suggested modification to the SC is "The user has the ability to have all scrollbars or equivalent controls displayed for all graphical viewports where the rendered content extends beyond the viewport dimensions. This ability overrides any values specified by the author. (Level A)"
Kim notes that sometimes expanding viewport is better than adding scrollbars.
Greg notes that open ACTION-240 is addressing, various ways of handling cases where content overflows containers.
<AllanJ> discussion of scroll bar implementation
Greg noted an instance of nested scrolling viewports, which causes extreme usability difficulties: http://sites.google.com/a/chromium.org/dev/developers/design-documents/accessibility/tracker
Jeanne and Jim discuss how in the chrome page example, keyboard navigation is very difficult, and Kim notes that scrollbars are difficult to control programmatically.
Issue: Guidelines for keyboard and mouse navigation in complex, nested scrollable areas and content
<trackbot> Created ISSUE-69 - Guidelines for keyboard and mouse navigation in complex, nested scrollable areas and content ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/69/edit .
Greg and Kim discuss the benefit of the ability to resize a viewport to the smaller of its content or its own container.
<scribe> ACTION: gl to create success criterion on resizing viewports to the smaller of their content or their own container [recorded in http://www.w3.org/2010/05/27-ua-minutes.html#action01]
<trackbot> Created ACTION-398 - Create success criterion on resizing viewports to the smaller of their content or their own container [on Greg Lowney - due 2010-06-03].
<AllanJ> ACTION: jallan to review definition of viewport to include frame, iframe, elements with 'overflow', object, form controls (select), screen, etc [recorded in http://www.w3.org/2010/05/27-ua-minutes.html#action02]
<trackbot> Created ACTION-399 - Review definition of viewport to include frame, iframe, elements with 'overflow', object, form controls (select), screen, etc [on Jim Allan - due 2010-06-03].
<AllanJ> Kim suggested that all viewport have a min, max, and scale controls,
<AllanJ> the UA needs toindicate which viewport has the focus. they viewport needs to be highlighted in some fashion so the user know where the next keyboard action will occur
Greg requests we collect examples where Web content raises difficult keyboard navigation problems.
<AllanJ> suggested rewrite of 3.10.5 "The user has the ability to have all scrollbars or equivalent controls displayed for all graphical viewports where the rendered content extends beyond the viewport dimensions. This ability overrides any values specified by the author. (Level A)".
<AllanJ> +1
<AllanJ> kf +1
<AllanJ> kp +1
Re what counts as a scrollbar, Greg pointed out example of Excel 2003 (and Jim adds Firefox) where you have a control to scroll through a list of tabs, but which does not provide any indication of what percentage of the field is visible.
Servant for the Mac replaced scrollbars with a control that simply showed you which direction had content, but didn't provide any indication of how much nor did it provide a mechanism for scrolling.
Similarly, in Windows, scrolling menus provide arrow buttons at top and bottom when there is content to scroll to, but no indication of how much.
Those are all examples of things that are much like scrollbars, but provide a subset of normal scrollbar functionality.
So which pieces of functionality are we going to require in 3.10.5?
Greg suggests if we have things like 3.10.12 (indicate viewport position) that require specific bits of scrollbar functionality, we don't need 3.10.5 that requires scrollbars specifically.
<AllanJ> kf: what is the end function we want
<AllanJ> gl: scroll bars tell you visually there is content beyond edge of viewport
<AllanJ> ... which direction the content lies
<AllanJ> ... position within the content (how much is viewable and./or outside viewport
Greg outlines the four uses of scrollbars: tell you when there's content outside of the viewport; tell you which direction it lies in; tell you which region you're seeing; and allow you to scroll the viewport.
<AllanJ> ... allows scrolling (moving position of content within viewport)
<AllanJ> need definition of scrollbar
We have several possible approaches: (1) require "scrollbars or equivalent" and give these four functionalities merely as examples; or (2) require "scrollbars or equivalent" and list some or all of the four functionalities as REQUIREMENTS to be considered scrollbar equivalents; or (3) ignore the concept of scrollbars and instead have four separate SC, one for each of the four functionalities, whic
h can have the same or different priorities.
I think the 3rd approach seems reasonable, given we already have SC like 3.10.12 which requires one of those four functionalities.
We can use "(e.g. scrollbars)".
Jim prefers using the term "scrollbar or equivalent" and defining that as requiring all four functionalities.
Greg notes that would result in increasing priority of "indicate viewport position" (3.10.12) from AAA to A.
Jim notes in Firefox, even when you can't see all the tabs, there is a control that displays a drop-down list of all tabs with your current tab highlighted.
Thus even though the viewport showing the list of tabs doesn't have scrollbars, there is an alternative way to get the same information/functionality.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ tin / to/ Succeeded: s/Smimil/Simil/ No ScribeNick specified. Guessing ScribeNick: Greg Inferring Scribes: Greg Default Present: Greg, allanj, KellyFord, Jeanne, sharper, Mhakkenin, kimpatch Present: KimPatch JimAllan JeanneS GregL MarkH KellyF SimonH Regrets: MHakkenin Found Date: 27 May 2010 Guessing minutes URL: http://www.w3.org/2010/05/27-ua-minutes.html People with action items: gl jallan WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]