- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 27 May 2010 13:54:09 -0500
- To: "'UAWG list'" <w3c-wai-ua@w3.org>
From: http://www.w3.org/2010/05/27-ua-minutes.html User Agent Accessibility Guidelines Working Group Teleconference 27 May 2010 See also: IRC log http://www.w3.org/2010/05/27-ua-irc Attendees Present KimPatch, JimAllan, JeanneS, GregL, MarkH, KellyF, SimonH Regrets Chair KellyFord Scribe Greg Contents * Topics 1. Survey http://www.w3.org/2002/09/wbs/36791/20100521/ * Summary of Action Items <trackbot> Date: 27 May 2010 <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 <AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010AprJun/att-0064/Position_ Paper_-_The_User_Context_2010-04-30.pdf 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. Survey http://www.w3.org/2002/09/wbs/36791/20100521/ <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/acces sibility/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. Summary of Action Items [NEW] 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] [NEW] 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] [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, 27 May 2010 18:54:46 UTC