See also: IRC log
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.
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
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]