W3C home > Mailing lists > Public > public-uaag2-comments@w3.org > September 2014

Re: Your comments on the W3C User Agent Accessibility Guidelines working draft

From: Silas S. Brown <ssb22@cam.ac.uk>
Date: Sat, 27 Sep 2014 16:13:12 +0100
To: Jeanne Spellman <jeanne@w3.org>
Cc: "public-uaag2-comments@w3.org" <public-uaag2-comments@w3.org>
Message-ID: <20140927151312.GA24870@snap.ds.cam.ac.uk>
Thanks Jim.

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 correct authentication, but that's not always
the case.)

Regarding SB02 (Reflow Text possible misunderstanding) - OK let's
hope the additional SC addresses the problem when it comes out.

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.)

Regarding SB04 (stop event handlers) - glad the example has been
added to the Reference to 2.11.3.  It comes up on quite a few sites.
Only problem now is: OK, so you can stop the scripts so they
can't cause the page to flicker, but then when you come to click
on the control, what if that click is processed ONLY by a script?
You are then in the position of having to (1) position the mouse,
(2) start scripts again, and (3) click.  (And hope that the
"flickering" problem doesn't start up again between steps 2 and
3, which it almost certainly will.)  So I think it would be very
nice to have some functionality that says "stop the scripts until
my next click - and when I click, start the scripts again just
before processing the click".

(And yes I do know that I can give keyboard focus to the
element, turn on scripts, and press an appropriate key, but that
might not work if the page's author did not think to implement a
keyboard alternative to clicking - a lot of Javascript-only controls
out there recognise only mouse events, unfortunately.  I hope there's
a guideline somewhere else that says it should be possible to
simulate mouse events by key presses.  But that's a different issue
- if you WANT to use the mouse to click on a control, and that
control is handled only by Javascript, and there's no way you can
approach the control with the mouse without stopping scripts first,
then it would be nice if there were some way of saying "please
turn Javascript back on just before processing this click".)

One other solution to this specific problem might be to have an
option that simply disables events like "onMouseEnter" and "onMouseOut"
- in other words, let me move my mouse around over the window
without telling any of the scripts on the page where my mouse
cursor is.  (Of course, when I click, THEN it will have to fire
the "onMouseEnter" event before the "click" event, otherwise a
lot of scripts might break.  But don't send the "onMouseEnter"
event when the user is just moving the mouse without clicking.)

Or perhaps all we need is (maybe not at level A, but maybe at
level AAA or something) - "automatically disable Javascript when
not interacting with the page".  I.e. when I click (or press any
button on the keyboard), enable scripts to handle that event, and
automatically disable them shortly after (how shortly?  ideally
"when the event handling is finished").  That way, we won't have
scripts messing up the display based on a background timer or
random mouse movements, but we can still use functions of a page
that are implemented in Javascript.

Although I still think it would make more sense to disable
specific Javascript events, rather than trying to turn on and off
the whole interpreter at the correct times.
"Disable Javascript timer events" and
"disable Javascript mouse-motion events" are definitely options
that I would switch on at nearly all times (except on sites where
you really can't get to the content without letting onMouseOver happen).

Perhaps it should be worded as something like "prevent scripts from
modifying the page in response to merely pointer motion", with a
suggestion that this might be implemented by stopping the entire
interpreter at appropriate times, or by suppressing certain
Javascript events - we say what result we want and leave it to
the browser implementors to decide how to do it.  (Really clever
implementors might want to let scripts run anyway but fail any
attempts they make to change the DOM, or allow changes to
proceed but don't actually display the result - but we needn't
go into that.  Stopping the interpreter or suppressing relevant
events should be fine, just as long as it's possible to switch
it all back on just before the crucial 'click' is processed.)

Regarding SB05 (adjustable time limits), yes I think the new
Section 2.9 is fine.

Regarding SB06, yes that's fine.


Received on Saturday, 27 September 2014 15:13:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:44 UTC