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
PresentJim_Allan, Jeanne, Kim_Patch, Greg_Lowney, JanRegretsKelly,
EricChairJimAllan,
KellyFordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/04/24-ua-minutes.html#agenda>
      1. CR02 guideline 1.4<http://www.w3.org/2014/04/24-ua-minutes.html#item01>
      2. CR03 <http://www.w3.org/2014/04/24-ua-minutes.html#item02>
      3. CR04 <http://www.w3.org/2014/04/24-ua-minutes.html#item03>
      4. CR05 general
comment<http://www.w3.org/2014/04/24-ua-minutes.html#item04>
      5. 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