Re: Discussion: Text Alternative Survey

ian wrote:

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

For conformance purposes it should not be appropriate under any
circumstances "to give the title in the title="" attribute." unless
the hidden content of the  title attribute is also available in an
input device independent manner.

regards

Stevef

On 24 April 2010 21:25, Ian Hickson <ian@hixie.ch> wrote:
> 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.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Sunday, 25 April 2010 06:52:29 UTC