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

Minutes: User Agent telecon 29 Oct 2015

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 29 Oct 2015 13:51:23 -0500
Message-ID: <CA+=z1Wnr+77J6KFvb7ufF2Nd8JrU_t=uqZ+q_yih98DgDAz97g@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
source: http://www.w3.org/2015/10/29-ua-minutes.html

​User Agent Accessibility Guidelines Working Group Teleconference 29 Oct
2015

See also: IRC log <http://www.w3.org/2015/10/29-ua-irc>
Attendees
PresentJim, Jeanne, Eric, Kim, GregRegretsChairJimScribeallanj
Contents

   - Topics <http://www.w3.org/2015/10/29-ua-minutes.html#agenda>
      1. 3.2.2 Describe Accessibility Features
      <http://www.w3.org/2015/10/29-ua-minutes.html#item01>
      2. 3.2.4 Changes Between Versions:
      <http://www.w3.org/2015/10/29-ua-minutes.html#item02>
      3. 3.2.5 Centralized View:
      <http://www.w3.org/2015/10/29-ua-minutes.html#item03>
      4. 3.3.1 Avoid Unpredictable Focus:
      <http://www.w3.org/2015/10/29-ua-minutes.html#item04>
      5. 4.1.1 Support Platform Accessibility Services:
      <http://www.w3.org/2015/10/29-ua-minutes.html#item05>
      6. 4.1.2 Expose Basic Properties
      <http://www.w3.org/2015/10/29-ua-minutes.html#item06>
      7. 4.1.3 Provide Equivalent Accessible Alternatives:
      <http://www.w3.org/2015/10/29-ua-minutes.html#item07>
   - Summary of Action Items
   <http://www.w3.org/2015/10/29-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 29 October 2015
3.2.2 Describe Accessibility Features

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

gl: this is tough to test or come up with implementation. need a list of
all UAAG features

eh: what does it mean to be explained in the interface?
... is the label enough? what is the minimal amount of information?

kp: point out the structure. here is help page, keyboard shortcut page,
settings page. would that be enough.

<Kim> Firefox Documentation:

<Kim> https://support.mozilla.org/en-US/products/firefox/get-started

<Kim> Firefox Keyboard Shortcuts list:

<Kim>
https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly?redirectlocale=en-US&as=u&redirectslug=Keyboard+shortcuts&utm_source=inproduct#w_current-page

chrome documentation:

https://support.google.com/chrome/?p=help&ctx=menu#topic=3227046

chrome keyboard shortcuts:

https://support.google.com/chrome/answer/157179?hl=en

gl: if documentation meets 3.2.3 then it will meet 3.2.2
... still a large task. There are lots of features to test

Note: we did not test every feature to document implementation

<scribe> scribe: allanj

*RESOLUTION: for 3.2.2 and 3.2.3*

Note: we did not test every feature to document implementation

Firefox Documentation:

https://support.mozilla.org/en-US/products/firefox/get-started

Firefox Keyboard Shortcuts list:

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly?redirectlocale=en-US&as=u&redirectslug=Keyboard+shortcuts&utm_source=inproduct#w_current-page

chrome documentation:

https://support.google.com/chrome/?p=help&ctx=menu#topic=3227046

chrome keyboard shortcuts:

https://support.google.com/chrome/answer/157179?hl=en
3.2.4 Changes Between Versions:

ja: UAs used to do this, now with auto updates perhaps they don't provide
feature changes as much?

chrome: log of all revisions by version
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=44202:43900&mode=html

http://googlechromereleases.blogspot.com/

<Kim> Firefox changelogs for each version:

<Kim> https://www.mozilla.org/en-US/firefox/releases/

*RESOLUTION: for 3.2.4*

chrome: log of all revisions by version

http://googlechromereleases.blogspot.com/

Firefox changelogs for each version:

https://www.mozilla.org/en-US/firefox/releases/
3.2.5 Centralized View:

<Kim> Documentation of accessibility features in Firefox

<Kim>
https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we

chrome: accessibility features for all products (chrome listed on the page)

https://www.google.com/accessibility/all-products-features.html

*RESOLUTION:*

Documentation of accessibility features in Firefox

https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we

chrome accessibility features for all products (chrome listed on the page)

https://www.google.com/accessibility/all-products-features.html

kp: apple missing stuff...thinks it is on the individual machine, no on the
web.
... things that apply to the machine also apply to all applications

gl: but there are unique accessibility features in safari that are not
documented (or we can't find it)
3.3.1 Avoid Unpredictable Focus:

gl: autofocus move in form fields (ssn, or phone)

kp: many cases on websites that disrupt interaction

can block autofocus with Greasemonkey

*RESOLUTION: 3.3.1 greasemonkey or something similar for IE, Chrome,
Safari, FF is a possible solution. No other implementation or extensions
were found.*
4.1.1 Support Platform Accessibility Services:

*RESOLUTION: Chrome, IE, Firefox, Safari do this*
4.1.2 Expose Basic Properties

what about selection?

screen readers know when something is selected. but can't find any
information in windows Inspect tool about selection

we are sure about all but 'selection', the browser knows what is selected
because you can copy from a browser

selection is covered in accessibility mapping
http://www.w3.org/TR/core-aam-1.1/#mapping_events_selection

though this is selection from a menu item, it is not selection of text in a
paragraph

*RESOLUTION: 4.1.2 Chrome, IE, Firefox, Safari support all except
selection. Need further investigation on selection*
4.1.3 Provide Equivalent Accessible Alternatives:

gl: first example in reference document is alternative way of doing
something, not an alternative to the API
... the second example is better
... platform AAPI is not about drag and drop, providing an alternative way
of doing the same task is a good thing, but does not apply to AAPI. the SC
is poorly worded. The intent provides much better explanation, but seems
unrelated to AApi
... don't have a real life example, of a UI element not supporting AAPI,
and the browser provided a work around
... when a browser can't provide programmatic access to an interface
control, it must provide another method method of access.

ja: anything on mobile?

kp: most things...no selection, no controls
... siri is starting to add some functionality, like start an application.
but backspace 3 characters...no, can't say backspace at all,.

<Greg> Example: A web browser [Internet Explorer] allows the user to choose
default colors for text, background, and so forth, using a color picker
control in which the user can click on any pixel in a field of overlapping
gradients. This control cannot be mapped to any standard control, and thus
cannot be easily exposed through MSAA or similar accessibility platform
services. Therefore screenreaders and

<Greg> other assistive technology cannot explain the control to the user
nor facilitate its use. To make the same functionality available to a wider
range of users, the same dialog box that displays the color picker also
allows the user to see and edit numeric values for hue, saturation,
luminosity, etc.

gl: its there for graphic designers, but helps people with disabilities...a
win, win

*RESOLUTION: 4.1.3 if the user agent has no custom controls it passes by
default.*

<Greg> That is, no custom controls that cannot be mapped to one or more
standard controls, and thus cannot be exposed through the platform
accessibility API (e.g. a gradient color picker cannot be exposed through
MSAA).

<Greg> IE uses a gradient color picker, so 4.1.3 requires it to provide an
alternative, and it does so with a set of numeric fields. Firefox, on the
other hand, uses a set of discrete color buttons for choosing color, which
can easily be exposed through the platform accessibility API, and therefore
is an N/A for 4.1.3 (at least for this particular set of controls).

<Eric> Accidentally dropped off when trying to unmute. Take care!

<scribe> chair: jim
Summary of Action Items [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, 29 October 2015 18:51:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 18:51:54 UTC