minutes: UAWG telecon 6 Nov 2014

from http://www.w3.org/2014/11/06-ua-minutes.html

[image: W3C] <http://www.w3.org/>
- DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 06
Nov 2014

See also: IRC log    http://www.w3.org/2014/11/06-ua-irc
<http://www.w3.org/2014/11/06-ua-irc>
Attendees
PresentJim_Allan, Eric, Jeanne, Kim_Patch, Greg_Lowney,
JanRegretsChairjimAllan,
KellyFordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/11/06-ua-minutes.html#agenda>
      1. tpac wrap-up <http://www.w3.org/2014/11/06-ua-minutes.html#item01>
      2. CSUN <http://www.w3.org/2014/11/06-ua-minutes.html#item02>
      3. Comments <http://www.w3.org/2014/11/06-ua-minutes.html#item03>
      4. MS01 def of UA
      <http://www.w3.org/2014/11/06-ua-minutes.html#item04>
      5. MS05 distinction for content, browser, AT
      <http://www.w3.org/2014/11/06-ua-minutes.html#item05>
      6. MS06 setting levels A, AA, AAA
      <http://www.w3.org/2014/11/06-ua-minutes.html#item06>
      7. MS08 stylesheets
      <http://www.w3.org/2014/11/06-ua-minutes.html#item07>
      8. SB01 1.74 save stylesheets
      <http://www.w3.org/2014/11/06-ua-minutes.html#item08>
      9. SB03 1.8.11 top level viewport focus
      <http://www.w3.org/2014/11/06-ua-minutes.html#item09>
   - Summary of Action Items
   <http://www.w3.org/2014/11/06-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 06 November 2014

scribe, allanj

<scribe> scribe: allanj
tpac wrap-up

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

jr: web-based user agents - not popular. js and jr reviewed UAAG to see who
would implement

<jeanne> Jan's email ->
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0049.html

jr: http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0049.html
... most of SCs are pass through and not a worry. there are a few that need
to be looked at. these could be placed in a separate section of the document
... SC - meet WCAG with some extra bits might help. worried about web-based
holding UAAG back

gl: its a matter of perception. and rewrite to make the what the actual
requirements are. worried about splitting the document.

jr: what above wcag is necessary for web=based UA, then link into document

js: perhaps non=normative, non-scary

jr: is there anything in UAAG that is separate and unique that is not done
by base browser, or not already a WCAG document, what doesn't
apply...what's left
... don't want to cover the entire internet.

eh: what is covered by this (web applications)

jr: reference document, but plump it up a bit to make it more understandable

eh: user has control vs app having control

gl: developer of app is also developer of content

eh: what is difference between an os based UA and and web-base tool.
... good to have a rationale on why they are separate, and differences
between browser types.

<jeanne> https://www.youtube.com/watch?v=cZiSPsaZ_Dc

<Jan> +1 to its coolness

js: symposium was fun...saw an app with 3d camera and you can play a
xylophone without touching a screen, knows where your head is in space in
relation to the keys and you can virtually play the instrument
... KP had a chat with Apple folks about speech interface issues. it is
being taken up by WebApps
... many groups reaching out to accessibility. they have non WAI
accessibility folks in their groups

jr: talked with the DPUB group, and we reinforced their accessibility
directions.

<Jan> Action item URL?

<trackbot> Error finding 'item'. You can review and register nicknames at <
http://www.w3.org/WAI/UA/tracker/users>.

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/ all recent
action items in email
CSUN

js: get a room and food at CSUN (end) have a day of testing specific SC,
OS, browser, at, etc.

kp: +1

<Jan> http://www.w3.org/WAI/UA/tracker/

js: need help, need to get the word out in december CSUN newsletter
... we could also meet at CSUN

kp: not sure how practical, but a good idea.

js: needs to be focused and organized tightly.

gl: we should be clear what the goals are...testing and awareness of UAAG

js: mostly promoting UAAG. give feedback to the browsers, filing a bug

gl: longer list of benefits...finding different browsers, mobile or
desktop, extensions, and other goodies
... if after CSUN, travel budgets, fewer people.

ja: during csun, a couple of hours.

js: CSUN negotiation for rooms.
Comments

http://jspellman.github.io/UAAG-LC-Comment/
MS01 def of UA

jr is working on a new proposal for this

js: review the comments on Web apps and work in to proposal
MS05 distinction for content, browser, AT

jr: in Reference Document - Implemented In section for each SC.

*RESOLUTION: MS05 done, jim to write cs about Reference document -
implement in section, after web-based solved*

js: also added @@core and @@techy for items that are core features and
those for super users

gl: will something like this remain in the final document.

jr: user facing features, A vs AA, or ???

js: more that it should be in the document or not

kp: if it is implemented well it is easy for users (even if it is
technical). or if it is shareable will be easier for users to use

jr: agree...balance with what is really important, what do we want the
developers to spend time on.

gl: do a better job in the intent, to explain what would be useful. easy
way for users to use stylesheets built by experts.
... some user agent only allows one user stylesheet, so no cascade.
... add What is Reccommended in the intent to flesh out what is useful and
how used by the user

jr: good idea.
MS06 setting levels A, AA, AAA

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

<jeanne> Last Call Comment Disposition ->
http://jspellman.github.io/UAAG-LC-Comment/LCcomments.html

eh: definition of web-based user agent, seems circular. user agent with Ui
based on a web technology.

jr: explains it.
... reason for new section to not scare people

micorsoft a, b, c, d for A, AA, AAA

a) interact with web content that meets WCAG 2.0, and

b) facilitate programmatic access of the content and its user interface to
and from AT, and

c) follow the accessibility settings from the OS, and

d) provide an user interface that is generally accessible, such as enabling
keyboard control on its own features when operating on an environment where
keyboard control is available, and

e) nothing more

so A SC should meet the above

and

Level AA should consist of success criteria that aid users in case of
common content failures and predictable solutions are available.

Level AAA should consist of success criteria that aid users in case of
content failures and where implementable solutions are available.

<Greg> I think that Microsoft's "A" criterion, saying that user agents
should only need to provide an accessible experience when viewing well
designed content that fully meets all of WCAG, is like saying cars should
be designed to be safe as long as everyone drives so carefully that the
cars never hit anything.
MS08 stylesheets

comment: Realistic expectation of the end users We still do not agree that
user stylesheets are a reasonable end user feature. User Stylesheets are
too technical to be an end user feature. They make sense only as a
programmatic interface available to AT developers. We would be satisfied if
the references to "users can" were changed to "AT can" or "developers can".

gl: didn't we demolish this last comment round

jr: what if we move 1.7.1, 1.7.2 to AA,
... so a mobile browser did all of 1.4 but not 1.7 do we want to fail the
browser.

js: Stylish app, easy to use. use it as a way for 1.7 to be implemented
easily
... user stylesheets don't exist on mobile so moving 1.7.1, 1.7.2 to AA,
leave 1.7.3 as A

PROPOSAL: 1.7.1 and 1.7.2 to AA

objections?

<Greg> I'm not thrilled with reducing these in priority, but I'll accept
the will of the group.

js: microsoft wants AAA

jr: we have implementations, so not too difficult. (stylish)

kp: not thrilled but OK

RESOUTION: move 1.7.1 and 1.7.2 to AA, MS08 done

gl: explain why... for the disposition document

js: writing them as we go along in the disposition docuemtns
SB01 1.74 save stylesheets

Regarding SB01 (not sure if 1.7.4 Save Copies of Stylesheets is really
needed), yes the new additional explanation is good, especially the point
about making sure the stylesheet is pretty-printed (which is not usually
possible if you simply inspect the page's source code and fetch the
stylesheet URLs from it, which is what I'm in the habit of doing).

Highly complex stylesheets can still be difficult to make sense of though,
even when pretty-printed. Some current browsers have "inspect this element"
functionality which can help here - they tell you exactly which CSS rules
were applied to the element you pointed at, and, as a bonus, include any
overrides that were generated by a script rather than a CSS file.

One addition that might be useful is in the case when a page's styles come
from not just one CSS file but quite a lot of them (I've seen sites with
over 20 CSS files all loaded from the same page, and no they weren't
alternates, they were ALL applied) - the user might choose whether to save
them individually or to merge. But I wouldn't worry too much about a
browser lacking that addition.

And one reason why it might be a good idea to have this function from
inside the browser (rather than relying on command-line tools like "wget")
is the page might be available only from behind a "login" page, and it's
often quite a chore to set up wget with the correct authentication cookies
just to get a copy of all the CSS files. (True, some servers will serve the
CSS files even without...

scribe: correct authentication, but that's not always the case.)

jr: css is difficult to make sense of, in the intent make clear that user
will use a tool to make sense of, edit, etc the css. all we want is for the
css to be saveable

*RESOLUTION: added paraphrase of statement above to intent of 1.7.4, SB01
done*

gl: add to the intent, "sometimes a page might have a number (10+) of css
applied. ideally the UA would allow the user to save these individually or
merged.
SB03 1.8.11 top level viewport focus

comment: (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.)

gl: sounds like a request for a new SC, to prevent various mouse buttons
from scripting events.

<Greg> It seems like he's saying we need a new SC where the user can
restrict which mouse buttons' behaviors can be customized by scripts.

jr: seems to be saying that. but the SC is only concerned about viewports
getting focus.

gl: comment seems not to be about this SC.

kp: this is very specific. there are probably lots of things like this we
could write SCs about.

jr: this may be relevant.

gl: SC to prevent scripting from opening new windows...
 Summary of Action Items [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