Disposition of Comments:
UAAG 2.0 and UAAG 2.0 Reference
Working Drafts of 25 September 2014

[done] Instead of removing web-based browsers from the scope of UAAG we have:

• labeled in UAAG Reference the SCs that typically are implemented at the web-based browser level
• added a section explaining this to the UAAG Introduction and/or conformance section
• changed the definition of user agent (#def-user-agent) in the glossary to give more specific guidance.

* 1.4.1 Basic text formatting (Globally):… Text scale with…
1.4.2 Basic text formatting (by Element): … Text size or scale

* 1.4.1 Basic text formatting (Globally):…
Text color and background color, choosing from all platform color options
Font family, choosing from all installed fonts [this says "installed" &
others say "platform"]
1.4.2 Basic text formatting (by Element):
Text color and background color, choosing from all platform color options
Font family, choosing from at least all platform fonts

1) * Current text: "Line spacing, choosing from a range with at least three values"
As it is written, a user agent that provided 1.0, 1.1, 1.2 would meet
this criteria; however, that doesn't meet the needs of most users who
need increased line spacing, as most need between 1.25 and 2.0.

SLH: Interesting way to cover it. Seems like it will work well along with the specific suggestions in the Reference. SLH: I note 1.4.1 says: * Line spacing, choosing from a range with at least three values up to at least 2 times the default * Text style, choosing to turn on/off underline, italic, bold and 1.4.2 says: * Line spacing, choosing from a range with at least three values * Text style (underline, italic, bold) Should these be the same or is there a reason that they are different?

SLH: [minor] "When it comes to magnification, size, or spacing, the optimum value for a given user would vary based on their visual impairment..." limits users who need this to people with visual impairment; however, many people with cognitive impairments also need uncommon text size and spacing especially. An idea to make it more broadly encompassing and simple is to replace the first sentence with: "Users have varying needs for text size and spacing."

> UAWG added a sentence to the Intent of 1.4.1:
>http://w3c.github.io/UAAG/UAAG20-Reference/#sc_141-i
> At a minimum, it is recommended to offer line spacing options of 1, 1.25, 1.5 and 2.0.

SLH: I agree that it's good to leave some flexibility in the normative standard and then provide specific suggestions in the informative Reference. Good work!

No specific response. Her email ends with "I am fine with all the other changes noted above."

[done] UAWG decided that 1.4.2 was important for people who do not necessarily use AT, and there are implementations using user stylesheets or in Extensions. UAWG added a section in Reference "Applies To" for each success criteria.

SLH: In the latest Editor's draft, I am still not able to find the following for element-level: * Margins * Borders (fyi, These seem to be commonly-used ways to help indicate different heading levels by advanced user stylesheet users, e.g., see <http://www.tader.info/ex-displays.html>)

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

SLH: I agree that most UAs today provide zoom at any increment - yeah! I do still think it is *very important that the standard include what users need*, even if it is already implemented in today's UAs -- to ensure that it is included in future UAs. (fyi, A common UA today provides the following zoom options in its interface: 10, 25, 50, 75, 100, 125, 150, 200, 400, 800, 1600, 2400, 3200, 6400. So between 150% and 400% --probably the most commonly-needed range-- there is only one option: 200%, which leaves out a lot of users' needs.)

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

element, e.g.,

Hello world.

element and make that its name, since its redundant. In this example, the name of the paragraph would be "Hello world", and the content would also be "Hello world". However, if the author wanted to call out that a particular paragraph is the summary of the current section, they could to the following:

Lorem ipsum dolor sit amet, consectetur ...

[done] UAWG does not feel that it is a bad thing for different AT to provide different user experiences. Such differences can be influenced by many factors, only one of which is their choice of gathering information via the DOM, platform API, and/or UA-specific means. We believe, that the field generally agrees, that diverse user experiences, and allowing the user to choose the tool that best supports their needs, is not only good but important. Typically, tools relying on platform API alone are able to provide a baseline-level of functionality across many applications, but other tools are able to provide a richer experience for specific applications by using a richer API. Users may choose one or the other based on their situation and needs. We believe that UA should support both approaches, and other reviewers have concurred, so DOM access is retained at Level A.