See also: IRC log
<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
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
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: 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: 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
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].
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: allanj Inferring ScribeNick: allanj Default Present: Jim_Allan, Jeanne, Kim_Patch, Greg_Lowney, Jan Present: Jim_Allan Jeanne Kim_Patch Greg_Lowney Jan Regrets: Kelly Eric Found Date: 24 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/24-ua-minutes.html People with action items: jan jeanne[End of scribe.perl diagnostic output]