W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

10 Dec 2015

See also: IRC log

Attendees

Present
jim, jeanne, kim, greg
Regrets
eric
Chair
Jim
Scribe
allanj

Contents


http://w3c.github.io/UAAG-Implementations/Implementations-by-feature

<Greg> https://w3c.github.io/UAAG/UAAG20-Reference/#sc_1810

http://w3c.github.io/UAAG/UAAG20/

must publish by Jan 5, 2016

w3c maratoriaum - last day to publish Dec 17

1.4.5 https://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0055.html

<Greg> Jeanne will check on how we should handle sections of the document that say "normative", which may or may not be appropriate when the document is now going to be a Note.

<scribe> scribe: allanj

calling the vote to publish the note...

+1

<Greg> +1

<jeanne> +1

<Kim> +1

RESOLUTION: Group agrees that UAAG 20 Note should be published

<Greg> Per Kim's suggestion, our proposal document should say that the future document should include use cases to provide UA developers with real-world examples that help them understand the users' needs and pros and cons of different potential solutions.

<jeanne> For the intro to Solution section: Allof the examples are addressed in UAAG 2.0, but they are still problems for people with disabilities. Since the need still exists, they should be repeated in a forum that is more acceptable to the user agent vendors.

<Greg> Might want to add to "are still problems for people with disabilities" "because they are not yet consistently implemented by user agents."

<Greg> (Don't want them to think it's because UAAG20 is insufficient.)

<jeanne> Many (most? all?) of the examples are addressed in UAAG 2.0, but they are still problems for people with disabilities because they are not yet consistently implemented in the browsers and user agents. Since the need still exists, these examples should be repeated.

<Kim> Provide a means for users to change and coordinate keyboard shortcuts across applications. Provide a way for users to save and share keyboard shortcuts.

<Greg> Remove repeated "browsers should implement html5 and ARIA".

<jeanne> All of the examples are addressed in UAAG 2.0, but they are still problems for people with disabilities because they are not yet consistently implemented in the browsers and user agents. Since the need still exists, these examples should be repeated.

<Greg> To "code around the deficiencies of user agents" could add "and their solutions may fail in some user agents".

wiki page to edit - https://www.w3.org/WAI/UA/work/wiki/DRAFT_-_Input_to_Guidelines_from_UAWG

<Kim> Here's some use case language for the keyboard shortcut item above: Keyboard shortcut control is important because different users have different needs. For example, single key shortcuts are good for keyboard users, but disastrous for speech users. It's important that users be able to save and share keyboard shortcut so users can share with each other and trainers can quickly set people up...

<Kim> ...with standard defaults for particular types of users.

<Greg> The "Solutions" list seems to equate to "do 5.1.1, do 5.1.2, and do all the rest".

<Greg> Maybe instead we should say the solution is to implement UAAG20, with particular emphasis on 5.1.1 and 5.1.2. We could also say something beyond UAAG20, such as recommending the incorporate accessibility into their processes such as testing, beta testing, and developer training.

<jeanne> Kim's comment: The difference between UAAG 2.0 and a future requirements document: UAAG was based on WCAG model, but while it is important for authors to use one solution to a user problem, the user agents can design different solutions to the problem. We hope it would be more effective to have use cases of disability needs for user agent vendors than to have a strict document like UAAG 2.0.

kim: everything is a moving target. new use cases will arrive next month.
... as landscape changes, the same issues discussed in UAAG will continue to appear in each new context

js: how would we organize a solutions document?
... we followed a POUR model, with standards and platforms.

<jeanne> kim: Organized along lines of what would be useful categories for developers

kp: focus on developers, not users. what categories do developers need

by type of user agent

mobile, desktop, media

input, output

<Greg> If you want to include a statement like "polyfills are hacks - bad for accessibility" you should justify it by explaining why they're bad.

<jeanne> rendering engine vs user interface

UI, rendering engine, interaction model (mouse, keyboard, touch, gesture, etc), output (printing,etc), API interface

<jeanne> not a specification, but rather a guidance document, including using PwD in design and usability

<jeanne> Kim: Having a video of something going wrong.

kp: video of user failing

<Greg> If we were working on a general guidance document instead of a standard we could include a lot of things beyond the technical implementation, such as process steps like including people with a range of disabilities in usability and beta tests, providing early development copies to accessibility ISVs, etc.

Implementation chart

1.1.7 Allow Resize and Reposition of Time-based Media Alternatives:*

*youtube - captions on top or bottom of video

(http://www.whooshtranscription.com/how-to-set-the-position-of-subtitles-on-youtube/

<http://www.whooshtranscription.com/how-to-set-the-position-of-subtitles-on-youtube/>)*

vlc player - captions/subtitles

https://wiki.videolan.org/Documentation:Subtitles/

For 1.6 decided to only test with ChromeVox. as it is an extension and by our definition it is part of the browser. All other screen readers are separate applications and are not covered by UAAG.

*1.6.1 Speech Rate, Volume, and Voice:

chromevox - rate, volume, voice*

1.6.2 Speech Pitch and Range:

chromevox - pitch only. http://www.chromevox.com/keyboard_shortcuts.html

1.6.3 Advanced Speech Characteristics: none known

1.6.4 Synthesized Speech Features:

all - only for external screen readers.

chromevox - read character by character, punctuation - on/off, no

exceptions, one way to read numbers,

1.6.5 Synthesized Speech Language:chromevox - yes

trackbot, close meeting

<trackbot> Sorry, allanj, I don't understand 'trackbot, close meeting'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Group agrees that UAAG 20 Note should be published
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/10 19:36:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Many (most? all?) /All/
Succeeded: s/most importantly/with particular emphasis on/
Succeeded: s/ and training./ and developer training./
Found Scribe: allanj
Inferring ScribeNick: allanj
Default Present: jim, jeanne, kim, greg
Present: jim jeanne kim greg
Regrets: eric
Found Date: 10 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/10-ua-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]