Re UAAG20 comments from Dominic Mazzoni of Chrome

Hello! Here are my draft responses to the comments on UAAG20 from Dominic Mazzoni (dmazzoni@chromium.org <mailto:dmazzoni@chromium.org>) of the Chrome group (http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0001.html):


    DM: * Chrome has a general philosophy that users should not be presented with too many settings or switches to control. Settings that are only enabled by a small minority of users increase the perceived complexity for everyone else and also increase the number of possible configurations for the developer to support and test. We prefer many such features to be available via extensions or add-ons instead. This document contains a large number of recommendations for additional configurations a user can specify, presumably via a specific option or setting built-into the browser.

    DM: What do you think about having extensions available for each of these features, rather than building them into the browser? Would Chrome be considered compliant with this spec if we implemented all of these guidelines as extensions and published an easy-to-use catalog of these for users to browse and install the ones they want?


GCL: We recognize that additional user options represent added burden for the developer in all phases, including design, implementation, testing, documentation, and support.  We explicitly state that the user agent can comply using both built-in features and extensions.  However, this approach is definitely inferior to making the features built-in. For example, it increases difficulty for users to find the features, particularly if there isn't a universally obvious way of referring to them when searching, or if the sheer number of available extensions is overwhelming, if the platform allows developers to charge for the extensions, if the extensions lag behind new versions of the user agent or development stops altogether, if the extensions are not supported to the extent the base user agent is, if various extensions prove incompatible with each other, etc. Of course, some of these problems go away if the the user agent manufacturer builds, distributes, and supports the 
extensions themselves.

    DM: The "Implementing" spec even references Firefox add-ons, like Text Equivalent Expand Abbreviations. Do the spec authors feel that such features should be built into the browser, or merely that such an option must be available to users?


GCL: As stated above, these can be provided as extensions.

    DM: * Settings that allow the user too much control over the layout and formatting invariably cause some web pages to be unusable. As an example, the minimum font size setting can be great for accessibility. However, it can make many websites with more complicated layouts unusable because the relatives sizes of text vs other elements on the page can now be off by a substantial margin. In contrast, most browsers now support a "zoom" feature that magnifies all elements on the page proportionally. To a web author, this is equivalent to the user modifying the width of the window, a case that already needs to be handled gracefully.

    DM: I don't feel that we should be telling users that they can't use a website because the web author is making the text too small, or using a font that's inaccessible to them. However, it's also counterproductive to give the user so much control that too many sites become impossible to use, and web developers will have no incentive or ability to fix their sites since there are so many permutations they need to support.

    DM: For example, I worry that the ability to change line spacing, character spacing, or justification might create more compatibility problems than they solve accessibility problems. I don't have any objection to allowing the user to specify font subsitutions, in comparison.


GCL: Your point is well taken that some pages break to greater or lesser extent when the user changes view options. Unfortunately, for many users the "zoom" feature does not provide an accessible view of the page in the way that increasing font size does; we try to address these issues in the Implementing document when explaining why overriding font size is so important. For example, greatly enlarging images along with text can make documents very difficult to use, as can making the user constantly scroll a viewport back and forth, and preventing them from seeing content that changes because it's scrolled off the side of viewport; there are many other examples. Also keep in mind that while enlarging text may break some pages, the page may be just as unusable for a user without it, and of course many, many pages will work with it just fine. Thus, we feel the user benefits from the ability to try different configuration settings for any give site to find the the ones that best 
meet their needs while they're performing their current task on the particular site. In addition, by making these user controls more widely available and better known, it increases awareness among and pressure on web content developers to make their sites compatible with these user options.

    DM: * Some of the recommendations seem overly technical and narrow: for example, the use-case for Show Element Hierarchy is that a user might want to write a custom stylesheet and needs to determine the path to a particular element within a page to write a style rule for it. However, there are already more innovative solutions to this problem available. A popular Chrome extension, StyleBot, lets the user simply click on any element on the page and modify the custom stylesheet with a friendly dialog interface. They can explore the classes that this element belongs to and apply the same style change to all elements in that class. My concern is just that these guidelines should not specify one narrow solution to a problem that precludes a more clever implementation.


GCL: Again your point is well taken. It is certainly true that better solutions can be provided, but I don't feel that providing this base-level fallback feature would discourage better approaches. (It's also true that there are additional use cases for this feature, such as a user of assistive technology that wants their screen reader to notify them when a region of the document changes, or when they want to set up shortcuts  that move focus or a magnifying window between specific locations.)

    DM: * Many of the guidelines are specific to a desktop computer, and written in a way that's too narrow to apply to a web browser running on a phone, tablet, or other device that may not have a keyboard. The guidelines should be written in a way that explain the user need and don't assume that a keyboard is available.


GCL: We entirely agree; any success criterion that relies on a physical keyboard, visual output, or other platform dependencies should be scoped in its own language. Please let us know of any success criteria that don't sufficiently address this.

    DM: * Many of the guidelines suggest features that are already available in existing assistive technology - for example opening an elements list, navigation by headings, or using voice control to jump to an element. Do the guidelines really mean to suggest that the browser should reimplement these as browser features rather than making them features of the AT? It's not clear to me that browsers should be providing these features directly - rather, they should expose rich information to AT via accessibility APIs, and allow AT to innovate ways to present this information to diverse groups of users.


GCL: There are certainly features which are only applicable to users of assistive technology, and almost anything *could* be delegated (or relegated) to assistive technology. However, there are some features that benefit users who would not require assistive technology. The disadvantages of relying on assistive technology include all of those mentioned above in regard to providing features as extensions, but even more so. Regarding your specific examples, note that 2.5.2 (Provide Navigation by Heading and within Tables) is implemented by extensions for some browsers, and while the Implementing document may suggest features such as navigation by voice where speech input is already supported, I'm not sure they are required anywhere. We'd appreciate it if you could be more specific about any success criteria you feel should not be implemented in the user agent or extensions.

    DM: * Guideline 2.6 suggests that "users can discover what event handlers (e.g. onmouseover) are available at each element". This is impossible to implement - it's quite commonplace for a web author to install a global event listener, or an event listener on a container element, and decide what to do depending on the target element of each event that bubbles up.


GCL: In this case the success criteria is actually limited to "recognized input methods explicitly associated with an element", so the user agent is not expected to present the user with a list that includes every possible event being handled by a global event listener, if the specific technology does not allow it to tell which specific events are being watched for. However, if the user agent can tell, for a given element, which events are being listened for by a element-specific, container element, or global listeners, it should be able to make this list available to the user. If you still feel this is a problem could you please elaborate?

     Thanks,
     Greg