Fwd: Re: Chrome review of UAAG LC?

Forwarded to the public list with permission from Dominic. Some info has 
been deleted at his request.

He is also interested in attending a few UAWG meetings to discuss his 
comments.

jeanne
-------- Original Message --------
Subject: Re: Chrome review of UAAG LC?
Date: Mon, 13 Jan 2014 01:16:32 -0800
From: Dominic Mazzoni <dmazzoni@chromium.org>
To: Jeanne Spellman <jeanne@w3.org>, David Tseng <dtseng@google.com>, 
Alice Boxhall <aboxhall@google.com>, Peter Lundblad 
<plundblad@google.com>,  Ian Ellison-Taylor <ianet@google.com>

Hi Jeanne,

Thanks for the opportunity to give feedback. I'm cc'ing a few of my
colleagues who might also be really interested in reviewing this if they
have time. David, Alice, and Peter are other engineers who work on Chrome
accessibility, and Ian and Greg are Chrome Directors. The comments below
are my own personal take, we haven't had a chance to craft a unified
response.

I think the idea behind almost all of these recommendations is very good.
I'd love for us to implement many of them in Chrome, and it makes sense for
users to have access to most of these features. However, I have a number of
concerns about the details of these recommendations. Here's my feedback.

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

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?

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?

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

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.

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.

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

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

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

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


- Dominic

On Fri, Jan 10, 2014 at 12:18 PM, Jeanne Spellman <jeanne@w3.org> wrote:

> Hi Dominic,
>
> I wanted to let you know that the working group extended the comment
> period for UAAG Last Call Working Draft after several people asked for more
> time.  I REALLY want input from Google.  I would want to hear from both
> mobile and desktop browser teams, if possible.
>
>
> UAAG 2.0 <- http://www.w3.org/TR/UAAG20/
> Implementing UAAG 2.0 <- http://www.w3.org/TR/IMPLEMENTING-UAAG20/
>
> Comments close on 31 January.  Please send comments to
> public-uaag2-comments@w3.org
>
> I hope you can make the time to take a look at it.  Let me know if you
> have any questions.
>
> Regards,
>
> jeanne
>
>
> On 12/11/2013 12:49 PM, Jeanne Spellman wrote:
>
>> Hi Dominic,
>>
>> I'm sorry this is late, I thought I had sent it last week, but didn't
>> find it in my Sent mailbox.  I wanted to send a personal invite in case
>> you don't receive the routine WAI announcements of publications.  Please
>> let me know if you need more time for review, since I know you are
>> getting this email later than I wanted.
>>
>> User Agent Accessibility Guidelines Working Group (UAWG) recently
>> published the Last Call Working Draft of the User Agent Accessibility
>> Guidelines (UAAG) 2.0. The UAWG would appreciate feedback from Chrome,
>> especially from the Chrome mobile teams.
>>
>> You may also want to consider reviewing "Implementing UAAG 2.0", which
>> provides more explanatory material on the the intent of each success
>> criterion, examples of ways that the success criterion could be
>> implemented, and additional resources and cross-references.
>>
>> UAAG 2.0 <- http://www.w3.org/TR/UAAG20/
>> Implementing UAAG 2.0 <- http://www.w3.org/TR/IMPLEMENTING-UAAG20/
>>
>> Comments on this working draft are due on or before 16 December 2013.
>> Please let me know if you need additional time.  Comments on the draft
>> should be sent to public-uaag2-comments@w3.org
>>
>> If the mobile development teams are interested, we published a list of
>> the mobile examples from UAAG last June. They are published at:
>> http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20130606/mobile.html
>>
>> Thank you for your interest and time.
>>
>> Regards,
>>
>> jeanne
>>
>> Jeanne Spellman
>> Staff Contact, UAWG
>>
>>
>>
> --
> _______________________________
> Jeanne Spellman
> W3C Web Accessibility Initiative
> jeanne@w3.org
>

Received on Tuesday, 14 January 2014 15:01:15 UTC