WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen reader interpretations of images in text (not part of a link)

for

From: Birkir R. Gunnarsson
Date: May 7, 2012 12:59PM

Even if all of these attributes can be programatically associated wit
an image, I do not believe screen readers treat them all in the same
way.
I know that the title attribute is often not read by default, and have
been correcting documentation that says it is essentially equivalent
to alt text and that alt textis not needed if title is present.
Whether this is by design or because screen reader manufacturers have
not done their homework is something I don't know, but I do know that
if we start relying on title, there will be issues in many SR/browser
combinations.
I'm worried that if we give developers too many alternatives to make
images accessible, it may simply backfire and we start seeing issues
arising fron inconsistent interpretation of different Assistive
Technology applications of these different attributes.


On 5/7/12, Steve Faulkner < <EMAIL REMOVED> > wrote:
> Hi Jared,
>
> "As has been noted, an image with no alt attribute and one with alt=""
> are treated identically."
>
> this is not always the case depends on the context the image is used in as
> previously noted when an image is the sole content of a link it is not
> ignored in many screen readers.
>
> "As far as WCAG is concerned, the alternative text success criteria has
> an associated failure that requires an alt attribute. Because no alt
> and alt="" for decorative images are treated exactly the same, it
> seems odd to me that one is a WCAG failure and the other not."
>
> success or failure techniques are not normative [1]
>
> So for example depending on the required accessibility support [6] the
> following
>
> <img aria-label="alt text">
>
> <img aria-labelledby="altext1">
>
> <img title="alt text">
>
> <figure>
> <img>
> <figcaption>text alternative</figcaption>
> </figure>
>
> Could all conform to the criteria 1.1.1 [2] "All non-text content that is
> presented to the user has a text alternative that serves the equivalent
> purpose" because they all provide [3] "Text that is programmatically
> associated with non-text content or referred to from text that is
> programmatically associated with non-text content. "
>
>
> you wrote:
>
> "In HTML5, the alt attribute is currently optional."
>
> I think it is more correct to say that it may be omitted in one
> circumstance: when a programmatically associated text alternative is
> provided using the figure/figcaption elements. [4]
>
> There are no other circumstances where it may be omitted. There is
> currently a circumstance whereby conformance checking tools may suppress
> errors relating to missing alt , but that does not mean the document is not
> invalid due to its absence. Also note that this clause is under dispute and
> could well be removed [5]
>
> you wrote:
> "If the alt attribute is
> required, the author must either give them alt="" or make up some
> bogus alt text (alt="photo") in order to be valid HTML. This
> essentially declares the images as accessible when they are not. By
> leaving off the alt attribute, the site would be valid HTML (though
> still not WCAG compliant) and the user would at least be identified to
> the presence of the images so they can do something with them if they
> choose to. This all, of course, relies on screen readers treating
> alt="" and no alt attribute differently - which they should eventually
> do with HTML5."
>
> Note the site would only be valid HTML5 if it used figure/figcaption. This
> photo site use case is resolved by the use of figure/figcaption I provide
> detail and examples of this and a bridging technique (until
> figure/figcaption is better supported) in section 3.12 When a text
> alternative is unknown at the time of publication of HTML5: Techniques for
> providing useful text alternatives [7]
>
>
>
> [1] http://www.w3.org/TR/WCAG-TECHS/intro.html#suff-adv-techs
> [2] http://www.w3.org/TR/WCAG20/#text-equiv
> [3] http://www.w3.org/TR/WCAG20/#text-altdef
> [4] http://dev.w3.org/html5/alt-techniques/developer.html#m6
> [5]
> http://www.w3.org/WAI/PF/HTML/wiki/Text_Alternatives/Meta_Generator_Decision_Comments
> [6]
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
> [7] http://dev.w3.org/html5/alt-techniques/#sec12
>
>
> WCAG definition of text alternative:[3]
> "Text that is programmatically associated with non-text content or referred
> to from text that is programmatically associated with non-text content.
> Programmatically associated text is text whose location can be
> programmatically determined from the non-text content."
>
>
> regards
> Stevef
>
> On 7 May 2012 17:37, Jared Smith < <EMAIL REMOVED> > wrote:
>
>> As has been noted, an image with no alt attribute and one with alt=""
>> are treated identically. For end users, this is a good thing. It would
>> be most unpleasant if all images that are missing alt attributes were
>> identified by a screen reader.
>>
>> As far as WCAG is concerned, the alternative text success criteria has
>> an associated failure that requires an alt attribute. Because no alt
>> and alt="" for decorative images are treated exactly the same, it
>> seems odd to me that one is a WCAG failure and the other not.
>>
>> alt=" " (space between the quotes) is never correct.
>>
>> In HTML5, the alt attribute is currently optional. The idea is that
>> alt="" makes a declaration - the image is decorative or the
>> alternative text is presented elsewhere (such as in adjacent text or a
>> caption). These types of images should always be ignored (assuming
>> they are not the only thing in a link, in which case alt="" would not
>> be appropriate anyway).
>>
>> An image with no alt attribute is ambiguous. It means, "The author did
>> not or could not provide alternative text." In this case, a screen
>> reader could identify the presence of the image and perhaps read the
>> image file name or do something else with it.
>>
>> While there are many opinions on this approach, I generally think
>> optional alternative text in HTML5 could be better for accessibility.
>> As an example, if a user uploads many vacation photos to a web page
>> and decides not to give them alternative text, the page will always be
>> inaccessible and will always violate WCAG. If the alt attribute is
>> required, the author must either give them alt="" or make up some
>> bogus alt text (alt="photo") in order to be valid HTML. This
>> essentially declares the images as accessible when they are not. By
>> leaving off the alt attribute, the site would be valid HTML (though
>> still not WCAG compliant) and the user would at least be identified to
>> the presence of the images so they can do something with them if they
>> choose to. This all, of course, relies on screen readers treating
>> alt="" and no alt attribute differently - which they should eventually
>> do with HTML5.
>>
>> Of note is that there are cases in HTML5, such as with
>> <figure>/<figcaption>, where no alt attribute is appropriate and
>> optimal for accessibility. This currently puts WCAG and HTML5 in
>> conflict with each other.
>>
>> Jared Smith
>> WebAIM
>> >> >> >>
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
> > > >