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

Re: Discussion on open bugs (ACTION-26)

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Tue, 27 Apr 2010 07:45:58 -0500
Message-ID: <w2r1c8dbcaa1004270545o19f0a1e4oeddc985e086c6c04@mail.gmail.com>
To: Michael Cooper <cooper@w3.org>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Michael,

>  is the task force comfortable with this documentation existing as an external resource?
>  Or does the task force believe it is critical that this stuff be in the spec itself?

My view it is a matter of degree.

* If a bug presents a critical problem it should be normatively specified.
* If a bug does not presents a critical problem shipping it off to a
non-normative doc is fine.

However, lumping them all together and shipping them all off into a
non-normative document may save time, but I fear we may be sacrificing
an accessible HTML5.

Some sort of agreed to criteria (I’m not sure what) should be applied
to each bug to help us decide what constitutes a critical problem.

I have repeatedly asked about defining bug criteria and started a Wiki
page on it:

Best Regards,

On Mon, Apr 26, 2010 at 8:12 PM, Michael Cooper <cooper@w3.org> wrote:
> For ACTION-26, I am tasked to propose what to do with some bugs that we
> previously wanted to track.
> 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.
> 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. And to increase accessibility, we might
> prefer that a different rule be applied, since accessibility features have
> historically been more likely to be "done wrong" than other features.
> 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.
> I do feel that somewhere we need to document the accessibility
> considerations of implementing new HTML features in user agents. The
> question I want to pose is, is the task force comfortable with this
> documentation existing as an external resource? Or does the task force
> believe it is critical that this stuff be in the spec itself?
> I need to answer this question in order to be able to make recommendations
> on the relevant bugs. If the task force thinks this stuff must be in the
> spec, my recommendations will be to take on the work items, get the needed
> information together, and push them through the process. Otherwise, my
> recommendations will be to take these into another forum and take them off
> the HTML accessibility task force immediate plate.
> We can discuss this by email, and I expect this question to be an agendum at
> this week's teleconference.
> Michael
> --
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org
> Information Page

Laura L. Carlson
Received on Tuesday, 27 April 2010 12:52:28 UTC

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