W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2015

Minutes: User Agent telecon 10 Dec 2015

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 10 Dec 2015 13:38:07 -0600
Message-ID: <CA+=z1W=HzBaUcr0z2AiiqrNWUr8jF-Ka1WccbKmaYbXnXMJrqA@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
source: http://www.w3.org/2015/12/10-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 10 Dec 2015

See also: IRC log <http://www.w3.org/2015/12/10-ua-irc>
Presentjim, jeanne, kim, gregRegretsericChairJimScribeallanj

   - Topics <http://www.w3.org/2015/12/10-ua-minutes.html#agenda>
      1. Implementation chart
   - Summary of Action Items
   - Summary of Resolutions



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


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


<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

<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

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

<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

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



vlc player - captions/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]

Jim Allan, Accessibility Coordinator
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
Received on Thursday, 10 December 2015 19:38:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 December 2015 19:38:39 UTC