WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Steve Faulkner
Date: May 8, 2012 3:22AM

Hi Birkir,
I do not and did not adocate using the title. or aria-label or
aria-labelledby to provide a text alternative for an image.

What I was attempting to convey was that all of these including alt are
candidates for providing the accessible name for an img element in HTML.

aria-label or aria-labelledby are checked first for a usable string because
this is the way that ARIA has been specified and implemnted.

Author advice is always to use native HTML features specified for providing
a text alternative (i.e. alt) and in HTML5 using aria-label or
aria-labelledby for the img element in the asebce of alt is not valid.


regards
steve

On 7 May 2012 19:59, Birkir R. Gunnarsson < <EMAIL REMOVED> >wrote:

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



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