Re: Discussion: Text Alternative Survey

On Sat, 24 Apr 2010, Laura Carlson wrote:
> > 
> > As I understand it the only proposed non-ARIA solution is 
> > <figcaption>, which is supported even less by ATs than title="".
> 
> I would be open to eliminating <figcaption> from the list of options, if 
> we do not have solid rationale for it.

We have a solid rationale for it -- the same rationale as title="" and the 
<h1> solution that we've now removed due to the implementation burden. 
(It's sad to see accessibility features removed because they're hard to 
implement, but that's life.)

The rationale is "in the scenario where the author knows the image is 
critical and has a caption for the image, but does not know what the image 
is, then it would be good to be able to semantically associate the image 
with the caption even for non-ARIA UAs". For example, Flickr, when 
rendered by a text browser like Lynx.


> I think it was Sean who pointed out that if we want the figure to be 
> equivalent to aria-labelledby we would need figcaption to be available 
> outside <figure>.

I don't see why we would want that. The idea of aria-labelledby is to 
express an annotation to be passed on to the OS accessibility layer. The 
<figcaption> element automatically conveys that annotation, by virtue of 
its link with the <figure> element. It doesn't really make sense to 
separate them, since then that role is lost. We already have a feature 
that just does the OS accessibility API annotation, that's ARIA.


> Are browser vendors actually ready to commit money and risk interop 
> issues over [<figure>]?

Yes, browser vendors have repeatedly indicated an interest in implementing 
<figure> and <figcaption>.


> >> Authors are advised to only use the title attribute for "additional 
> >> information" and not as a full equivalent alternative.
> >
> > The spec doesn't suggest using it as a full equivalent alternative.
> 
> I think that this may be a key point of confusion in all of this that we 
> need to clear up.

If there is any text in the spec responsible for this confusion, please 
let me know so that I can fix it.


> WCAG allows alt text alternatives values that identify and describe 
> purpose [2]. HTML5 doesn't.

WCAG is written in the context of HTML4, which required an alt="" 
attribute to be present even if the author has no alternative text to 
provide and only had a caption. In that context, it makes sense to say 
that if all you have is a caption, you would put the caption in the place 
of the alternative text, even if that is semantically dubious.

In HTML5, we avoid conflating the alternatives and purpose descriptions. 
This allows WCAG to suggest even more accessible solutions once ATs have 
adapted to the broader model defined in HTML5.


> I drafted a CAPTCHA survey last month [8]. It included Matt's idea of 
> providing a "captcha" role on img to give user agents and assistive 
> technologies a chance to call internal or cloud-based CAPTCHA solving 
> systems like Webvisum, and validation/evaluation tools to mark them as 
> an accessibility issue. Ian would you be open to something like this?

If there is a proposal for providing a CAPTCHA cloud API, I am very happy 
to consider it. Please file a bug.


> >> Removing title would make the HTML specification in line with WCAG, 
> >> and previous authoring practices. 
> >> http://www.w3.org/TR/WCAG20-TECHS/H33.html
> >
> > WCAG's recommendations are based on HTML4; the whole point here is to 
> > move forward. WCAG will need updating for HTML5.
> 
> It might help if we think of it as a two way street. WCAG will need 
> updating for HTML5 and HTML5 will need updating for WCAG. We are here to 
> try sort out how best to do that. Working together maybe we can figure 
> it out.

WCAG and HTML4's accessibility advice has been continuously taken into 
account in the development of HTML5.


On Sat, 24 Apr 2010, Laura Carlson wrote:
> >> > 
> >> > It violates layering by making it possible for removal of ARIA to 
> >> > affect conformance,
> >>
> >> Ian, could you explain this further? I did not attend the WAI CG 
> >> sessions when the ARIA options were added. We should have solid 
> >> rationale for the options listed. If layering is a problem, let's try 
> >> to figure it out here.
> >
> > Layering isn't a problem, it's an architectural design principle.
> >
> > ARIA is, by design, a layer above HTML (initially HTML4 and XHTML1) 
> > that adds annotations for ATs.
> 
> Is the principle argument relevant? Layering is not mentioned in the 
> HTML Design Principles [1].

I am not referring to the HTML Design Principles, but to basic language 
design principles, which apply to all language design.


> > To use it, one takes a conforming HTML document and adds ARIA to make 
> > it accessible.
> >
> > By definition therefore, removing ARIA can't make a document 
> > non-conforming. A proposal that would allow for a document to be 
> > written with ARIA such that removing the ARIA makes the document 
> > non-conforming is thus suffering from what we call a "layering 
> > violation".
> 
> In practical terms, in this case, how does a "layering violation" make a 
> difference?

Layering violations lead to complicated interdependencies. These tend to 
snowball as the technology matures. Layering violations are actually one 
of the most insidious problems in language design, because they appear 
inoccuous at first, and tend to accrete over time, leading eventually to a 
disaster. One example of this in the past with HTML was the tendency for 
presentational features to be mixed with semantic features, rather than 
keeping them separate (as we have now done with CSS and HTML5). Over time 
this led to a breakdown of the Web's accessibility, as more and more 
authors just used <font> and bgcolor="" and eschewed semantic markup that 
ATs could hook into. This led to ATs having to develop complex heuristics 
for, e.g., detecting data tables (heuristics so complicated that nobody 
has yet been able to describe them for inclusion in HTML5). Splitting 
presentational markup and semantic markup again has taken more than a 
decade (it started in HTML4, and is still ongoing), and is now so 
ingrained in how people think of the Web that we regularly get HTML 
working group members arguing that it's not really a problem.

In the particular case of ARIA being mixed into the HTML conformance 
layer, a simple example of a problem that would immediately be introduced 
is that if someone decided to redo the way the page maps to accessibility, 
they couldn't just remove all the ARIA annotations and start over, because 
doing so might make their document invalid. On the long run, it would make 
developing ARIA an increasingly difficult task as it would effectively 
couple ARIA and HTML -- instead of being able to revise ARIA independently 
when problem are found, any change to the image labelling in ARIA would 
require a revision of HTML, which would pull in the rest of the HTML spec.


> >> >  discourages use of semantic HTML by removing the
> >> >  allowance for using title="" for titles,
> >>
> >> Using title="" is problematic as it cannot be relied upon as alt can. 
> >> It is only safe to use for extra, advisory information.
> >
> > The point here is that there is no alt, because the author doesn't 
> > know what the image is. The spec is describing ways of giving the 
> > image's title or caption. If the image _did_ have alternative text, 
> > then it would be appropriate to give the title in the title="" 
> > attribute. What the spec is doing here is saying that in the case 
> > where there is no alt="" attribute, you can still give the title in 
> > the title="" attribute, and the UA/AT is expected to use that 
> > information.
> 
> I think I understand the reasoning behind "images whose contents are not 
> known" section now. That has baffled me for the longest time. It is an 
> attempt to mitigate damages. Right?

Yes. Sorry, I thought that was clear -- why would people be suggesting 
changes to it if they didn't understand what it was for?

Is there something I can add to the spec to make the intent of the section 
clearer?

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

Received on Saturday, 24 April 2010 20:25:37 UTC