RE: Minutes: UAWG telecon 24 April 2014

ACTION: jan to smith MS01 with zooming example:


In order to clarify the relationship between UAAG 2.0 and WCAG 2.0 (and ATAG 2.0) UAWG has added 2 new sections to the Guidelines document Introduction:

-Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0 and

-Relationship to the Authoring Tool Accessibility Guidelines (ATAG) 2.0


For the following reasons, UAWG continues to believe that keeping web-based user agents in the scope of UAAG is reasonable:

- from the perspective of users needing accessibility features (e.g. zoom, media navigation, etc.) it is not always clear whether a user agent is web-based or native, especially as browsers and operating systems converge.

- UAAG does allow web-based user agents to depend on the base (native) user agent in order to meet UAAG success criteria, just as non-web-based user agents can rely on operating system features (e.g. to programmatically communicate with assistive technology)

- the web-based user agent may be best placed to provide UAAG conformant functionality. For example a web-based video player may only be serving small portions of a video to the base browser's video player, so the base browser would not be able to provide effective navigation of the video. Similarly, a web-based user agent can zoom its content and keep its own user interface the same size, saving screen real estate, while the base browser's zoom function may zoom the web-based browser's user interface, leaving less space for the content.


Instead of de-scoping web-based user agents, UAWG will identify exemptions from specific success criteria where necessary (e.g. due to technical limitations).







Cheers,

Jan


(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca<mailto:jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E>

________________________________
From: Jim Allan [jimallan@tsbvi.edu]
Sent: April-24-14 2:36 PM
To: WAI-ua
Subject: Minutes: UAWG telecon 24 April 2014

http://www.w3.org/2014/04/24-ua-minutes.html

IRC log http://www.w3.org/2014/04/24-ua-irc

User Agent Accessibility Guidelines Working Group Teleconference
24 Apr 2014

See also: IRC log<http://www.w3.org/2014/04/24-ua-irc>

Attendees

Present
Jim_Allan, Jeanne, Kim_Patch, Greg_Lowney, Jan
Regrets
Kelly, Eric
Chair
JimAllan, KellyFord
Scribe
allanj
Contents

  *   Topics<http://www.w3.org/2014/04/24-ua-minutes.html#agenda>
     *   CR02 guideline 1.4<http://www.w3.org/2014/04/24-ua-minutes.html#item01>
     *   CR03<http://www.w3.org/2014/04/24-ua-minutes.html#item02>
     *   CR04<http://www.w3.org/2014/04/24-ua-minutes.html#item03>
     *   CR05 general comment<http://www.w3.org/2014/04/24-ua-minutes.html#item04>
     *   MS01<http://www.w3.org/2014/04/24-ua-minutes.html#item05>
  *   Summary of Action Items<http://www.w3.org/2014/04/24-ua-minutes.html#ActionSummary>

________________________________
Summary of Action Items
[NEW] ACTION: jan to smith MS01 with zooming example [recorded in http://www.w3.org/2014/04/24-ua-minutes.html#action02]
[NEW] ACTION: jeanne to smith CR05 response to make clear that nav by heading is required but not speech input nav by heading [recorded in http://www.w3.org/2014/04/24-ua-minutes.html#action01]

<trackbot> Date: 24 April 2014

<scribe> scribe: allanj

http://lists.w3.org/Archives/Public/public-uaag2-comments/

<jeanne> http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0005.html

discussion of github

current version of the guidelines - http://jspellman.github.io/UAAG/UAAG20/

<Jan> http://www.w3.org/WAI/UA/2014/LCcomments.html

CR02 guideline 1.4

gregs comments http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0016.html

<Greg> GCL: Your point is well taken that some pages break to greater or lesser extent when the user changes view options. Unfortunately, for many users the "zoom" feature does not provide an accessible view of the page in the way that increasing font size does; we try to address these issues in the Implementing document when explaining why overriding font size is so important. For example, greatly...

<Greg> ...enlarging images along with text can make documents very difficult to use, as can making the user constantly scroll a viewport back and forth, and preventing them from seeing content that changes because it's scrolled off the side of viewport; there are many other examples. Also keep in mind that while enlarging text may break some pages, the page may be just as unusable for a user...

<Greg> ...without it, and of course many, many pages will work with it just fine. Thus, we feel the user benefits from the ability to try different configuration settings for any give site to find the the ones that best

<Greg> meet their needs while they're performing their current task on the particular site. In addition, by making these user controls more widely available and better known, it increases awareness among and pressure on web content developers to make their sites compatible with these user options.

ja: I also think, its up to the user to be able to make changes. and uadjust to the edge of breaking the site to make it as useful as possible

<Jan> +1 to Jeanne's point

js: gregs answer is a good one. perhaps we need to review this with Wayne Dick, to deal with specificity.

jr: if one of the members makes a comment, then it becomes a proposed response and put in the comment document.

gl and ja and kp agree with JR

<Jan> http://www.w3.org/WAI/UA/2013/commentsWD.html

gl: the disposition table can be found at http://jspellman.github.io/UAAG-LC-Comment/

repository link for comments https://github.com/jspellman/UAAG-LC-Comment

all working on figuring out github

CR03

Some of the recommendations seem overly technical and narrow: for example, the use-case for Show Element Hierarchy is that a user might want to write a custom stylesheet and needs to determine the path to a particular element within a page to write a style rule for it. However, there are already more innovative solutions to this problem available. A popular Chrome extension, StyleBot, lets...

scribe: the user simply click on any element on the page and modify the custom stylesheet with a friendly dialog interface. They can explore the classes that this element belongs to and apply the same style change to all elements in that class. My concern is just that these guidelines should not specify one narrow solution to a problem that precludes a more clever implementation.

<Greg> GCL: Again your point is well taken. It is certainly true that better solutions can be provided, but I don't feel that providing this base-level fallback feature would discourage better approaches. (It's also true that there are additional use cases for this feature, such as a user of assistive technology that wants their screen reader to notify them when a region of the document changes, or...

<Greg> ...when they want to set up shortcuts that move focus or a magnifying window between specific locations.)

ja: this is a mix of general comment and a specific comment
... ok with gcl response
... any objections

none heard

<Greg> It is true that some of the success criteria have very technical and narrow requirements, and that other, more effective approaches to addressing the problems may be developed. However, we do not believe that requiring the base-level fallback feature discourages development or inclusion of more effective approaches.

<Greg> Proposed revised response: It is true that some of the success criteria have very technical and narrow requirements, and that other, more effective approaches to addressing the problems may be developed. However, we do not believe that requiring the base-level fallback feature discourages development or inclusion of more effective approaches. (It's also true that there are additional use...

<Greg> ...cases for this feature, such as a user of assistive technology that wants their screen reader to notify them when a region of the document changes, or when they want to set up shortcuts that move focus or a magnifying window between specific locations.)

RESOLUTION: accept greg comment in IRC

CR04

CR04: Many of the guidelines are specific to a desktop computer, and written in a way that's too narrow to apply to a web browser running on a phone, tablet, or other device that may not have a keyboard. The guidelines should be written in a way that explain the user need and don't assume that a keyboard is available.

GCL: We entirely agree; any success criterion that relies on a physical keyboard, visual output, or other platform dependencies should be scoped in its own language. Please let us know of any success criteria that don't sufficiently address this.

<Greg> GCL: We entirely agree; any success criterion that relies on a physical keyboard, visual output, or other platform dependencies should be scoped in its own language. Please let us know of any success criteria that don't sufficiently address this. Please keep in mind that even devices without physical keyboards are expected to support keyboard emulators and other types of assistive technology...

<Greg> ...that rely on keyboard emulation at the programming interface level.

we added a note to principle 2 - Note: Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. If every potential user task is made accessible via modality independent controls that any...

scribe: input technology can access, a user can use what works best. For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. Another example is a user on a mobile device that lacks keyboard who uses uses taps, wirelessly connected devices, and voice commands to...
... simulate discrete or keyboard input. See Independent User Interface: Events for additional information on APIs and techniques for modality independent controls.

keyboard interface

Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g. a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external...

scribe: keyboards that may be connected).

Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.

CR05 general comment

CR05: Many of the guidelines suggest features that are already available in existing assistive technology - for example opening an elements list, navigation by headings, or using voice control to jump to an element. Do the guidelines really mean to suggest that the browser should reimplement these as browser features rather than making them features of the AT? It's not clear to me that...
... browsers should be providing these features directly - rather, they should expose rich information to AT via accessibility APIs, and allow AT to innovate ways to present this information to diverse groups of users.

GCL: There are certainly features which are only applicable to users of assistive technology, and almost anything *could* be delegated (or relegated) to assistive technology. However, there are some features that benefit users who would not require assistive technology. The disadvantages of relying on assistive technology include all of those mentioned above in regard to providing features...
... as extensions, but even more so. Regarding your specific examples, note that 2.5.2 (Provide Navigation by Heading and within Tables) is implemented by extensions for some browsers, and while the Implementing document may suggest features such as navigation by voice where speech input is already supported, I'm not sure they are required anywhere. We'd appreciate it if you could be more...
... specific about any success criteria you feel should not be implemented in the user agent or extensions.

JR, JA, KP all agree with comment

RESOLUTION: accept gcl comment

CR comments are done!

<scribe> ACTION: jeanne to smith CR05 response to make clear that nav by heading is required but not speech input nav by heading [recorded in http://www.w3.org/2014/04/24-ua-minutes.html#action01]

<trackbot> Created ACTION-972 - Smith cr05 response to make clear that nav by heading is required but not speech input nav by heading [on Jeanne F Spellman - due 2014-05-01].

CR comments are 5/6, waiting on addiional input from Wayne dick

MS01

why is it marked incomplete?

gl: It is possible, without needing to change the main guidelines document, to create targeted documents that call out only a subset of the guidelines and success criteria, or filter them based on the feature set of a particular product.
... making analogy to atag

<scribe> ACTION: jan to smith MS01 with zooming example [recorded in http://www.w3.org/2014/04/24-ua-minutes.html#action02]

<trackbot> Created ACTION-973 - Smith ms01 with zooming example [on Jan Richards - due 2014-05-01].


[End of minutes]<http://www.w3.org/2014/04/24-ua-minutes.html>


--
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