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

minutes: User Agent telecon 4 Dec 2014

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 4 Dec 2014 13:35:06 -0600
Message-ID: <CA+=z1Wkoq05Q80pVTBhMf46Rm7MzvpLYpDXxHBkTebJcVyMfpA@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from: http://www.w3.org/2014/12/04-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 04 Dec 2014

See also: IRC log <http://www.w3.org/2014/12/04-ua-irc>
http://www.w3.org/2014/12/04-ua-irc
Attendees
 Present Eric, Jeanne, Jim_Allan, Greg_Lowney, Jan, Kim_Patch Regrets Chair
jimAllan Scribe allanj
Contents

   - Topics <http://www.w3.org/2014/12/04-ua-minutes.html#agenda>
      1. MS06 4.1.2 dom writing should be AA not A
      <http://www.w3.org/2014/12/04-ua-minutes.html#item01>
      2. MS06 4.1.4 dom writing should be AA not A
      <http://www.w3.org/2014/12/04-ua-minutes.html#item02>
      3. MS06 5.1.1 5.1.2 web-based UA
      <http://www.w3.org/2014/12/04-ua-minutes.html#item03>
      4. MS01 web-based UA
      <http://www.w3.org/2014/12/04-ua-minutes.html#item04>
      5. MS02 - GL1.6 AT
      <http://www.w3.org/2014/12/04-ua-minutes.html#item05>
      6. MS03 - 1.4.1 text format separation OS/AT
      <http://www.w3.org/2014/12/04-ua-minutes.html#item06>
    - Summary of Action Items
   <http://www.w3.org/2014/12/04-ua-minutes.html#ActionSummary>

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

 <trackbot> Date: 04 December 2014

3.1.4 spell check, should be A not AA

4.1.2 dom writing should be AA not A

5.1.1 5.1.2 web-based UA

MS01 - web-based UA

MS02 - GL1.6 AT

MS03 - 1.4.1 text format separation OS/AT

note to jeanne - there is no MS04 comment

close action-1052

<trackbot> Closed action-1052.

<scribe> scribe: allanj

open Item 1

proposed: if we cannot come up with a test, or no one champions an SC that
it gets eliminated.

js: if some SC doesn't have any implementation then remove

jr: mark as 'at risk' for CR

gl: is it only no test, or are there other circumstances being debated

jr: sure debate, but need to focus on a test

kp: like what JR said...AT RISK is good.

js: can only have 4 AT RISK
... anything beyond the 4 goes into a Best practices page on the wiki

1. no test or can't test - move to best practices

2. if test and 1 implementation - at risk

3. if test and no implementations - move to best practices

anything else...

<jeanne> +1

none heard

<Jan> @@1implementaion

<Jan> @@0implmentations

<Jan> @@1implementation - would help if I spelled it right

<Jan> @@0implementations

topic MS06 3.1.4 spell check, should be A not AA

http://jspellman.github.io/UAAG-LC-Comment/

<Jan> http://jspellman.github.io/UAAG-LC-Comment/

<Jan> MS comments email:
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html

we have already done this. decided to leave it as AA

mobile issues
MS06 4.1.2 dom writing should be AA not A MS06 4.1.4 dom writing should be
AA not A

MS06: 4.1.4 DOM could be AA. Providing AT developers a way to go around
accessibility APIs is not always a good thing, as it results in
inconsistent user experiences based on the AT developers interpretation.

gl: read access should be fine, but write access may be problematic ...
perhaps they meant 4.1.4 and 4/1/5

4.1.5

JAWS parses the html (dom?) when the A11y API is insufficient

<Greg> I disagree with the commenter's assertion that having different AT
provide different user experiences, based on their choices of how to
interpret information via the DOM or platform API or UA-specific means, is
necessarily a bad thing. Supporting diverse user experiences, and allowing
the user to choose the tool that best supports their needs, is generally
deemed good. If the user wants to...

<Greg> ...use a tool which provides a richer experience because it uses a
richer API (rather than the bare-bones platform API), that would ideally be
supported by the UA.

<Greg> On the other hand, DOM access would only be taken advantage of by AT
that special-cases the UA, and thus could be considered lower priority than
API (including the platform API) that is designed to support all (or nearly
all) AT with a minimum of special effort on the AT's part.

ja: sounds like you are still talking about read access
... unless the UA allows it the AT has no access to the DOM? is that
correct?

when IBM was on the group they strongly wanted 4.1.4 and 4.1.5

gl: not sure of implementations, but strongly support level A

jr: is there any information on mobile and a11y api and dom access

ja: inclined to level A based on IBM comments - they wrote the SC

<Jan> *ACTION:* JR to To run the SC in 4.1 past the PF API subgroup.
[recorded in http://www.w3.org/2014/12/04-ua-minutes.html#action01]

<trackbot> Created ACTION-1056 - Run the sc in 4.1 past the pf api
subgroup. [on Jan Richards - due 2014-12-11].

gl: have trouble with an extension having access to the DOM and bubbling
stuff up, but not allowing AT...seem counter intuitive
MS06 5.1.1 5.1.2 web-based UA

jr: we have support for media players, reader tools - epub, and others

<Jan> JR: I thought we had agreement that Mobile apps are covered as
follows: Natyive mobile browsers/native mobile media players are covered by
UAAG 2.0

gl: mobile app vs web app. mobile app is based on platform. web apps are
based in the browser

js: mobile and web apps are blurring

<Jan> JR: Then we would also provide some informative UAAG 2.0 stuff to
cover reader-type native apps (and reader-type web-based apps)

<Jan> JR: Then most other native mobile apps (airline booking apps, etc.)
are primarily covered by WCAG 2.0 (as will be better explained in the Note
that will come out of the WCAG-UAAG task force)

<Jan> http://cordova.apache.org/

<Jan> http://phonegap.com/

discussion of mobile app - native app or webview component in a wrapper
that works on various platforms.

gl: still don't see a difference between web and mobile app.

jr: developers excited about mobile apps...start with a webapp then wrap in
a platform container to create a mobile app

<Greg> That is, I don't really feel the distinction between native apps on
mobile and non-mobile platforms, both of which can (if they choose) host
web-based components is important.

<Jan> http://w3c.github.io/UAAG/UAAG20-Reference/#sc_331

<Jan> "Typically Implemented in"

jr: web-based user agent - when reviewed at f2f, most of the SCs were
complied with in the base browser (host browser, native browser). Only 25%
of SC need to be met by the web-based UA

<jeanne> UAAG Reference Editor's draft with added sections "Typically

<jeanne> Implemented in:"

<jeanne> http://w3c.github.io/UAAG/UAAG20-Reference/

<jeanne> Success criteria that applied to web apps and mobile apps
(primarily web

<jeanne> based readers) were:

<jeanne> 1.4 Text Customization

<jeanne> 1.8.3 Scrollbars & 1.8.4 Indicate Position in Content

<jeanne> 1.8.13 Multicolumn Text Reflow

<jeanne> 1.8.16 Web Page Bookmarks

<jeanne> 1.9.1 Outline View

<jeanne> 2.1.1 Keyboard functionality

<jeanne> 2.1.3 Avoid keyboard traps

<jeanne> 2.1.5 Follow Text Keyboard conventions

<jeanne> 2.1.6 Make keyboard access efficient

<jeanne> 2.7.1 Allow Persistent Accessibility Settings

<jeanne> 2.7 Preference Settings

<jeanne> 2.8.1 customize Display of Controls

<jeanne> 2.10 Avoid Flashing

<jeanne> 2.11 Time-Based Media

<jeanne> 3.1.1 Text Entry Undo

<jeanne> 3.1.2 Settings Changes can be Reversed or Confirmed

<jeanne> 3.2 Documentation

<jeanne> 5.1.1 Comply with WCAG

<jeanne> 5.1.2 Implement Accessibility Features of Content Specifications

<jeanne> 5.1.5 Allow Content Elements to be Rendered in Alternative Viewers

<jeanne> 5.1.6 Enable Reporting of User Agent Accessibility Faults

<Jan> "non-web-based UA user interfaces"

eh: discussion of definition of UA

<Jan> http://w3c.github.io/UAAG/UAAG20/#def-user-agent

eh: definition of UA has 4 architectures, but only 3 bullets

jr: what to folks think of Native user agent.

gl: platform-based UA is only in the glossary and in the conformance section
... most folks use 'native'

jr: like native, concern about java

<Greg> I like the term "native UA" because native is already being widely
used in the wider industry as the alternative to web-based. But as Jan
points out if we want to include UA written forcross-platform intermediate
platforms such as Java, then Native would not be appropriate.

the list SCs above is applicable to web-based UA

it is approximately 1/6 of all SCs

gl: would disagree with commenter that user agents only (missed the rest)

eh: concern for concept of base browser

jr: like term 'native browser' include in definition of UA

<Greg> UAAG as a document applies to all user agents, regardless of how
they are written. Being written in a particular language does not exempt it
from requirements that apply to all UA. However, some specific success
criteria only apply to UA written in specific technologies such as native
API or HTML/Javascript, etc., and those will be identified in the document.

proposed: use 'native' browser in definition. Call out Java based browser
and explain.

gl: but you write a browser in any language and run it anywhere. write a
windows browser and run in a windows emulator on Linux

<Greg> Note that even "native" applications aren't necessarily *really*
native. You can write an application for the Win32 API that then may be run
on top of a WINE emulator on top of Linux, etc. All applications are
written for an API, and usually don't know what's under that layer.

jr: to write a new definition of UA to include 'native' or base/host/parent
browser

<Jan> *ACTION:* Jan Try to work "native" and "base browser" into defn of
user agent [recorded in
http://www.w3.org/2014/12/04-ua-minutes.html#action02]

<trackbot> Created ACTION-1057 - Try to work "native" and "base browser"
into defn of user agent [on Jan Richards - due 2014-12-11].

<Greg> Note that whether a UA is stand-alone, hosting, or hosted is
independent of whether it is written as native to the operating
environment, or uses a host-based API, or is web-based.

<Jan> Resolution: Instead of removing web-based browsers from the scope of
UAAG we have labeled (in the reference document) the SCs that typically are
implmentesd at the web-based browser level and we will be adding a section
explaining this to the UAAG Introduction and/or conformance

*RESOLUTION: Instead of removing web-based browsers from the scope of UAAG
we have labeled (in the reference document) the SCs that typically are
implmentesd at the web-based browser level and we will be adding a section
explaining this to the UAAG Introduction and/or conformance section..*

s/implementesd/implemented

so does this also meet MS01
MS01 web-based UA

*RESOLUTION: Instead of removing web-based browsers from the scope of UAAG
we have labeled (in the reference document) the SCs that typically are
implmented at the web-based browser level and we will be adding a section
explaining this to the UAAG Introduction and/or conformance section.*
MS02 - GL1.6 AT

comment MS02: Separation of assistive technologies from user agents We
accept the UAAG disposition. However, we think it would be useful to take
some of the text from your response to our comment and add it as a note in
the document.

this may be editorial

previous comment

Providing guidelines for software that does synthesized speech does not
equate with targeting AT, which as you've noted is already explicitly
exempted. For example, early versions of the Kindle provided text to speech
that was not targeting people with disabilities; if browsers provide speech
output for mainstream users, they should be making the speech configurable
enough to be usable by a...

scribe: wide range of individuals. When an extension adds speech output to
the UA, it becomes part of the UA, and, should meet the requirements of
1.6. UAWG clarified 1.6.3 to apply only to UAs that provide synthesized
speech.

above from Nov 2013.

*RESOLUTION: UAWG will add a Note to the beginning of 1.6 - something like
- if browsers provide speech output for mainstream users, they should be
making the speech configurable enough to be usable by a wide range of
individuals. When an extension adds speech output to the UA, it becomes
part of the UA, and, should meet the requirements of 1.6. .*
MS03 - 1.4.1 text format separation OS/AT

comment MS03: Separation between browsers and OS We still believe that
1.4.1 should be separated into a level A criterion to pick up the OS
settings where they exist, and level AA or level AAA criterion to go beyond
the settings available on the platform.

<jeanne> *ACTION:* jeanne to smith the Note prefacing 1.6 [recorded in
http://www.w3.org/2014/12/04-ua-minutes.html#action03]

<trackbot> Created ACTION-1058 - Smith the note prefacing 1.6 [on Jeanne F
Spellman - due 2014-12-11].

<scribe> *ACTION:* Jallan to review MS03 comment. fix as needed [recorded
in http://www.w3.org/2014/12/04-ua-minutes.html#action04]

<trackbot> Created ACTION-1059 - Review ms03 comment. fix as needed [on Jim
Allan - due 2014-12-11].

close action-1039

<trackbot> Closed action-1039.
 Summary of Action Items *[NEW]* *ACTION:* Jallan to review MS03 comment.
fix as needed [recorded in
http://www.w3.org/2014/12/04-ua-minutes.html#action04]
*[NEW]* *ACTION:* Jan Try to work "native" and "base browser" into defn of
user agent [recorded in
http://www.w3.org/2014/12/04-ua-minutes.html#action02]
*[NEW]* *ACTION:* jeanne to smith the Note prefacing 1.6 [recorded in
http://www.w3.org/2014/12/04-ua-minutes.html#action03]
*[NEW]* *ACTION:* JR to To run the SC in 4.1 past the PF API subgroup.
[recorded in http://www.w3.org/2014/12/04-ua-minutes.html#action01]

[End of minutes]

-- 
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>Jim Allan,
Accessibility Coordinator & Webmaster
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, 4 December 2014 19:35:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:46 UTC