Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

On Thu, 21 Jan 2010, Richard Schwerdtfeger wrote [reordered]:
> > >
> > > The intent is to include the vocabulary in CSS to form a media query 
> > > in harmony with HTML 5 to choose the best content for the user.
> >
> > Let the user choose what is best for them. You can't know if I prefer 
> > an E-book reader or a high-contrast option. Which I prefer can change 
> > from minute to minute.
>
> nobody is saying you cannot. Selection should be a browser feature but 
> not a content feature unless the author chooses to do that.

Can browser vendors confirm that they are willing to prominently expose 
this new selection UI?


> I also don't want to force the author to show both at the same time. You 
> are basically forcing authors to insert a selection mechanism using 
> script on every page they write.

Not at all -- this is a very rare occurance in practice. Most <canvas> 
elements can be written in such a way that the fallback really is media- 
independant and accessible, in a way that works both for users with canvas 
and users without. In fact I've yet to see a real example where this is 
_not_ the case, despite asking for one several times.


> > > 2. longdescription i.e. <visual longdescription = "true">
> > >
> > > This might be a solution for a drawing where an alternative 
> > > interactive solution is not provided but it is the best thing 
> > > available.
> >
> > Why is <a href=""> not suitable for this? Or even just an inline <p>? 
> > Or simply regular fallback in <canvas>, with the UA offering the user 
> > with the option to switch to the non-canvas view? A long description 
> > is useful for people with particular acceessibility needs, but it is 
> > not limited to those users, and thus we should not hide such 
> > descriptions from them. A regular link on the page is quite suitable 
> > for this purpose.
>
> You may want the content to rendered in prose on the page vs. having the 
> user go to another page to look at it. Why make the user go elsewhere 
> when they just want to see different information.

Either is fine, indeed. I'm a big proponent of having longer descriptions 
on the same page as the image/table/widget.


> > > 3. ATinteroperable <visual ATInteroperable = "true">
> > >
> > > This might be a solution for an application that is interoperable 
> > > with an assistive technology, like a screen reader, but does not 
> > > support desktop font and color settings. A blind user does not care 
> > > if an application supports high contrast settings.
> >
> > Isn't that simply a description of what HTML supports by default?
>
> Only if the author made the content AT Interoperable using standard 
> controls, ARIA, etc.

Well, sure, but if they don't then this whole conversation is moot since 
they certainly won't be providing fallback in that case either.


> And yes, the blind user does not care about high contrast settings. They 
> only care about AT Interoperable. In the same mind set a color blind 
> user does may not care about being AT Interoperable. This allows the 
> provision for the user to decide what collection of properties need to 
> be satisfied.

The whole point of HTML is that we can provide a _single_ description that 
handles _all_ of these cases. I object to adding features to HTML that 
subvert the very architecture that makes HTML so emminently suitable as a 
media-independent, multi-platform, _accessible_ application language.


> > > 4. <visual e-book="true">
> > >     <object ... "ebook plug-in">
> > >
> > > Let's say someone wants to use <canvas> the equivalent of a kindle 
> > > UI on a web page. It is inaccessible but if it has an e-book 
> > > alternative it could be rendered.
> >
> > As a user with no current need for ATs, I would still appreciate that 
> > alternative. Why would we hide it? This should be a front-and-center 
> > option made available to all users.
>
> Not everyone may want this.

Hence offering it as a choice.


> Some may not want the clutter.

I've demonstrated that this adds no clutter in real world situations.


> Some may simply want the text book vs and read it themselves vs. a 
> digital talking e-book.

Sure. I'm saying that the page should give the user those options.


> Again, you are specifying your personal preference. So, making something 
> available to everyone and letting someone choose what they want are not 
> the same.

How do they differ?


> > > > >         <label> <input type=checkbox name=l checked> Bulleted
> > > > >         List</label>
> > > > >       </menu>
> > > > >   </visual>
> > > > >   <visual>
> > > > >   </visual>
> > > > > </canvas>
> > > >
> > > > This would cause a non-supporting UA to show both sets of content, 
> > > > which wouldn't work.
> > >
> > > A user agent will do what the spec. provides for. This would be 
> > > driven by CSS Media queries.
> >
> > Non-supporting UAs such as those shipping today would render both sets 
> > of content. There's nothing we can write in any spec anywhere that 
> > will change what those browsers do, however hard we try.
>
> sure we can. We can specify how the browser is suppose to process 
> content. That was something you asked us to do for ARIA.

I think you misread what I wrote. I'm talking here of software that has 
already shipped to users, and is already installed on end-user hardware, 
and is already in use by end users. This software is already written and 
shipped. The specifications cannot in any way change what that software 
does when it ships, since it has already shipped.

Naturally we can affect _future_ browsers. But I'm talking about being 
compatible with _already shipped_ browsers, such as IE8, Firefox 3.6, 
Safari 4, Opera 10.


> > > Could you show me how the user, independent of site chooses which UI 
> > > is rendered in such a form that does not clutter the page?
> >
> > You don't do it independent of site. You just provide a link and the 
> > user clicks it.
>
> Taking people elsewhere is disorientating. This is old style HTML 
> development where you ask people to load an entirely new page for one 
> piece of content. Imagine a mashup doing that for each service loaded 
> into a page.

It doesn't have to be a new page. It's common for UIs to update inline.


> > For example, consider a very uncluttered page:
> >
> >    http://www.google.com/
> >
> > It has an "Advanced Search" link which provides an alternative modality.
> > Or alternatively, consider:
> >
> >    http://www.google.com/finance?q=IBM
> >
> > An alternative modality could easily and unobtrusively be provided 
> > under the graph where it currently says "Settings | Plot feeds | 
> > Technicals" etc.
> 
> Again, you are pushing the burden off to the author.

I do not consider this a negative. I think it's a positive.


> Again, the burden is put on the author. Not all sites want to do this.

The burden of creating an alternative modality is orders of magnitude 
greater than the burden of making that alternative available in a link. If 
the authors aren't willing to provide a link, then they also aren't going 
to be willing to provide the alternative and it's pointless trying to 
invent new features to address those authors.

In fact, I would argue that those authors are _more likely_ to provide 
a working alternative (fallback) content for <canvas> if it is as simple 
to do so as is currently described in the spec, than if it needs a 
complicated multiple-media mechanism such as that which you describe.



> > > Then the UA does not support HTML 5. Either it supports it or it 
> > > does not. You are asking us to support accessibility of a markup 
> > > that is not fully supported.
> >
> > Yes. We have to, since right now "not supporting" is the majority 
> > case, and it'll be _a_ case for many years to come. HTML5 is designed 
> > from the ground up to be backwards-compatible, which means being 
> > accessible in both legacy UAs and new UAs.
>
> If that were true some would not be asking that table summary be 
> removed.

This is a non-sequitur; _removing_ a feature from the _language_ doesn't 
affect legacy user agents at all; it's only _adding_ features that can 
cause graceful-degradation problems for legacy user agents.


> So, I disagree with this assertion. We want to make things better in 
> HTML 5 and there are instances where we have been picking and choosing, 
> to our convenience, what you choose to be backward compatible.

It has to be the case that content written for new user agents can render 
in legacy user agents. Your proposal fails to handle this case.


> > > We need to allow the author to choose what content is rendered and 
> > > this fallback mechanism for browsers that do not support an HTML 5 
> > > breaks that capability.
> >
> > I do not agree with the premise of this statement. We do not need to 
> > allow the author to choose what content is rendered. The *user* has to 
> > have that choice.
>
> I think both statements are true. What I am saying is that the user 
> can't tell the author he can't offer alternatives.

I do not understand this statement, and I do not see how it matches the 
statement quoted above.


> What I am saying is that different alternative visual mediums may be 
> required for some users. Not all users are blind. Some are cognitively 
> impaired and simplified visual content may be provided for some content 
> as an alternative. I think you are assuming the fallback content will 
> satisfy everyone's needs. It may not.

Sure. Authors who provide alternatives should -- and are -- able to expose 
those alternatives. There is no language-level problem to solve here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 22 January 2010 23:09:46 UTC