User Agent Accessibility Guidelines Working Group Teleconference -- 11 Dec 2014

<trackbot> Date: 11 December 2014

Kelly's resignation

<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0072.html

<scribe> scribe: allanj

open item 2

<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/User_Agent_Capabilities

<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Platform_Capabilities

<Kim> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Note:_WCAG_2.0_and_Mobile

kp: Platform Capabilities feeds into the Note. Platform is background
... trying to get everyone on the same page about mobile
... need help filling out UA capabiliites
... what are topic needed?

ja: APIs (accessibility, keyboard, etc.)
... user setting separate from platform settings

kp: speech input...where does it live. On the platform, or separate application
... gap in command and control (CNC) on the platform.
... if CNC was in UA would be better, if speech followed keyboard.

ja: plugins for extra capabilities for the UA

kp: how does wcag, uaag, and mobile all come together

jr: no real platform accessibility requirements (touch system)

eh: what is the overlap between UAAG and WCAG

jr: good topic. all about end user experience.

ja: you test WCAG in the browser

eh: UAAG has stuff for repair,

jr: more limited now.

js: user style sheet in the platform and UA

eh: browser as platform

jr: user css is in the UA not the platform

close item 2

MS01 - web-based UA Action-1057 -Jan

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0068.html

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0073.html

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0074.html

eh: simple def. in glossary, with lots of extra information about specific cases in some other part of doc (perhaps conformance)
... a lot of the info is useful but non-normative.

jr: important to keep "Note: Many web applications retrieve, render and facilitate interaction with very limited data sets (e.g. online ticket booking). In such cases, WCAG 2.0, without UAAG 2.0, may be appropriate for assessing the application's accessibility."
... UA should apply to browsers only. Need the NOTE to limit the scope of the definition.
... perhaps a link in the def to the expanded information

<jeanne> That reminds me, we also need to move the Conformance note that says that if the platform doesn't allow it, it doesn't apply. That needs to be in the Applicability Notes so it is easier to find.

eh: perhaps in the applicability notes.
... if it is essential then put in conformance section. otherwise elsewhere.

proposal: use Native to replace non-web-based browser.

<Jan> ACTION: JR to Propose a shift of much of the explanatory material from user agent defn to a note in the conformance area [recorded in http://www.w3.org/2014/12/11-ua-minutes.html#action01]

<trackbot> Created ACTION-1060 - Propose a shift of much of the explanatory material from user agent defn to a note in the conformance area [on Jan Richards - due 2014-12-18].

RESOLUTION: use Native to replace non-web-based browser.

close action-1057

<trackbot> Closed action-1057.

MS03 - 1.4.1 text format separation OS/AT Action-1059 - Jim

4.1 sanity check

jr: 4.1.2 selection and focus are state.
... if the UA supports an accessibility API (4.1.1) then the references are the PF document.

<jeanne> ACTION: jeanne to update UAAG to change the term "non-web-based" to "native" [recorded in http://www.w3.org/2014/12/11-ua-minutes.html#action02]

<trackbot> Created ACTION-1061 - Update uaag to change the term "non-web-based" to "native" [on Jeanne F Spellman - due 2014-12-18].

ja: 4.1.2 is the UA version of a WCAG SC 4.1.2

jr: does UAAG need stay heavy on the API stuff (a strength of PF), or focus on user interface
... keep 4.1.1, 4.1.4 and remove the others.
... the others in 4.1 will be difficult to test.

<Jan> http://www.w3.org/TR/core-aam-1.1/

jr: want to finish, keep it simple.
... need to wait for GL input

<Jan> http://www.w3.org/TR/ATAG20/#gl_a12

<Jan> A.1.2.2 Platform Accessibility Services:

<Jan> If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. (Level A)

<Jan> Note: The (optional) explanation of conformance claim results should record the platform accessibility service(s) that were implemented.

<scribe> ACTION: jeanne to move the Conformance note that says that if the platform doesn't allow it, it doesn't apply. That needs to be in the Applicability Notes so it is easier to find. [recorded in http://www.w3.org/2014/12/11-ua-minutes.html#action03]

<trackbot> Created ACTION-1062 - move the conformance note that says that if the platform doesn't allow it, it doesn't apply. that needs to be in the applicability notes so it is easier to find. [on Jeanne F Spellman - due 2014-12-18].

eh: Applicability Notes and relationship to Conformance. some statement needed
... what do we want to call attention to

SB03 - 1.8.11 Allow Top-Level Viewport Focus Control

comment: Regarding SB03 (1.8.11 Allow Top-Level Viewport Open on Request), I believe the problem I mentioned is caused by scripts intercepting the "mousedown" or "mouseup" event (rather than the "click" event), and therefore intercepting middle-clicks and (unintentionally?) causing these to perform some action on the page instead of opening the link in a new window. One solution might be to...
... allow the user to specify which mouse buttons are allowed to generate Javascript events. For example, if the user says "do not allow any mouse buttons to generate Javascript events" then no click or mousedown / mouseup events are generated and clicks always perform the default browser behaviour; if the user says "allow only the left mouse button to generate Javascript events" then the...
... other buttons will not; if the user says "allow left and right but not middle" then pages can override context menus but cannot override whatever the middle button is bound to (e.g. "open in new tab"). I'm not sure how exactly these options should be described to the user, or where to put them (probably in an "advanced" section somewhere), but being able to tell the browser not to...
... generate JS events when I middle-click would stop a lot of annoying sites from overriding this "open link in new tab" shortcut. (Yes, there will be times when the site is so script-driven that "open in new tab" can't work anyway, but in these cases the user would find out soon enough; I find in most cases "open in new tab" certainly CAN work - and DOES work when you bring up the context...
... menu and select it from that - but the site simply prevents middle-click from doing that job.)

<jeanne> Conformance 8.Platform Limitations: If the platform (hardware or operating system) does not support a capability necessary for a given UAAG 2.0 success criterion, list the success criterion and the feature (e.g. a mobile operating system does not support platform accessibility services, therefore the user agent cannot meet success criterion 4.1.2). For these listed features, the user agent can

<jeanne> claim that the success criteria do not apply (see 9.b.1 following). This should move to Applicability Notes

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

<Eric_Hansen> Sorry need to drop off now.

ja: doesn't seem to apply.

js: too device specific...middle mouse button.

RESOLUTION: Not Accepted - UAWG is unconcerned with how the new window opens, this SC is only concerned about IF the new window captures focus.

<jeanne> ACTION: jeanne to update the comment for SB03 to say that middle-button-click is too technology specific and see resolution for the rest of the comment response. [recorded in http://www.w3.org/2014/12/11-ua-minutes.html#action04]

<trackbot> Created ACTION-1063 - Update the comment for sb03 to say that middle-button-click is too technology specific and see resolution for the rest of the comment response. [on Jeanne F Spellman - due 2014-12-18].

ms01 web-based UA

jr: craft definition for epub, media player, etc. eliminate mobile apps, etc

MS03 1.4.1 text formatting

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.

ja: the UAs already do 1.4.1

for reference: 1.4.1 Basic text formatting (Globally): The user can globally set all of the following characteristics of visually rendered text content: (Level A)

* Text scale with preserved size distinctions (e.g. keeping headings proportional to main font)

* Text color and background color, choosing from all platform color options

* Font family, choosing from all installed fonts

* Line spacing, choosing from a range with at least three values

jr: we say this is what the UA should do for text. MS says Level A should be OS level stuff.
... UAs don't always respect OS text settings

ja: after thinking, not sure any UA meets the comment requirements

jr: we are concerned about getting implementations.
... in the intent, make it clear the inheriting OS setting could help meet 1.4.1

close item 5

close item 7

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

11 Dec 2014

Attendees

Contents