W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2010

Re: Discussion on open bugs (ACTION-26)

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 29 Apr 2010 08:22:07 +0000 (UTC)
To: Michael Cooper <cooper@w3.org>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <Pine.LNX.4.64.1004290747220.14147@ps20323.dreamhostps.com>
On Mon, 26 Apr 2010, Michael Cooper wrote:
> There are a number of bugs that request more specification of the user 
> agent behaviour (in particular, keyboard support) for certain features. 
> For the most part these are marked as "won't fix" with an explanation 
> that it is not for the spec to prescribe user agent behaviour, but that 
> of course user agents must handle the features in an accessible manner 
> as they must for all features.

User agent _interface_ behaviour. Obviously we have to describe UA 
behaviour, that's the point of the spec. :-)

> On the one hand, I see that point. On the other hand, the spec does
> prescribe user agent behaviour in many ways. It is not obvious to me
> what divides the features that are prescribed in the spec, from the
> features that are left to user agent variability.

The distinction is between what is UI-agnostic UA behaviour and what is 
UI-specific UA behaviour.

If there are UI-specific requirements in the spec, please file bugs. In 
most cases, those are mistakes. (There's a few special cases where I have 
included UI requirements; those are generally either for accessibility or 
security reasons, and even those should generally only be "SHOULD"-level 

> Instead of expecting this sort of stuff to appear in the spec, another 
> solution to this concern would be to have some kind of non-normative 
> user agent guidance document that explains the accessibility issues of 
> implementing various HTML features and suggests ways of addressing them. 
> Even if user agent developers don't follow the exact design patterns in 
> that document, at least the issues they need to consider are there. This 
> could be a "HTML5 user agent accessibility guide", or could be something 
> we'd hope to see in Implementing UAAG 2.0 
> <http://www.w3.org/TR/IMPLEMENTING-UAAG20/>.

Indeed, that seems like exactly the right way to go.

The reasons UI behaviour is not something we should spec are many. For 
example, we don't want to restrict UAs to only doing what we can think of 
today. For example, consider what would have happened if previous versions 
of HTML had said each page had to be rendered in its own window, without 
mentioning tabs. Another example is that different UAs can be aimed for 
very different users. While most browsers today are aimed at all users, 
it's easy to imagine that some could be aimed only for the blind, say. It 
wouldn't make sense to require that such a browser be able to show 
captions. Similarly, if I wrote a browser just for myself, it shouldn't be 
considered non-compliant just because I didn't make it possible to get to 
title="" attributes without a mouse -- I can use a mouse. That doesn't 
mean it's ok to do that in a general-purpose browser, but the spec can't 
usefully distinguish between the two in a normative way.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 29 April 2010 08:22:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:35 UTC