See also: IRC log
<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.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
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
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.
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. .
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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/components/components is important/ Succeeded: s/include non-native, /include UA written for/ FAILED: s/implementesd/implemented/ Found Scribe: allanj Inferring ScribeNick: allanj Default Present: Eric, Jeanne, Jim_Allan, Greg_Lowney, Jan, Kim_Patch Present: Eric Jeanne Jim_Allan Greg_Lowney Jan Kim_Patch Found Date: 04 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/04-ua-minutes.html People with action items: jallan jan jeanne jr try[End of scribe.perl diagnostic output]