See also: IRC log
<trackbot> Date: 06 November 2014
scribe, allanj
<scribe> scribe: allanj
<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
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.
http://jspellman.github.io/UAAG-LC-Comment/
jr is working on a new proposal for this
js: review the comments on Web apps and work in to proposal
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.
<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.
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
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.
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...
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/it is being taken up by ATAG/it is being taken up by WebApps/ Found Scribe: allanj Inferring ScribeNick: allanj Default Present: Jim_Allan, Eric, Jeanne, Kim_Patch, Greg_Lowney, Jan Present: Jim_Allan Eric Jeanne Kim_Patch Greg_Lowney Jan Found Date: 06 Nov 2014 Guessing minutes URL: http://www.w3.org/2014/11/06-ua-minutes.html People with action items:[End of scribe.perl diagnostic output]