WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Ryan Hemphill
Date: May 7, 2012 3:40PM

2 cents on a technical note:

I'd like to mention that aria-label is (at least for now) a bad idea when
it comes to VoiceOver. I've seen cases where there is a huge and ugly lag
time - I don't recommend it.

- Ryan

On Mon, May 7, 2012 at 3:46 PM, Steve Faulkner < <EMAIL REMOVED> >wrote:

> Hi Birkir,
>
> NOTE: I did not say that it was correct to use the title attribute, or that
> we should be advocating its use the same goes for aria-label and
> aria-labelledby for the <img> element:
> As I state in http://dev.w3.org/html5/alt-techniques/#secm7
>
> The title attribute *must not* be used to provide a text alternative for an
> > image. The title attribute *must not* be used to provide a caption for an
> > image, use the figure and figcaption elements to provide a caption, as
> > described above.
>
>
>
> What I was illustrating was that It is programmatically associated text
> that is required by WCAG not the alt attribute. The current reality is
> though, that the most robust method of providing a programmatically
> associated text alternative is using the alt attribute.
>
> But all of the attributes attributes I used in the example map to the same
> property in accessibility API's. This is by design
> The algorithm that browsers use to provide the accessible name for an <img>
> element can is [1]:
>
>
> 1. Use aria-labelledby
> 2. Otherwise use aria-label
> 3. Otherwise use alt attribute
> 4. Otherwise use title attribute
> 5. If none of the above yield a usable text string there is no
> accessible name.
>
> [1] http://www.w3.org/TR/wai-aria/roles#namecalculation
>
>
> you wrote:
> "I know that the title attribute is often not read by default"
>
> This very much depends on what element it is on.
>
> regards
> Stevef
>
> 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
> > > > > > > > > > > >
> > > > > > > >
> > > >



--



Shipping is a Feature...Perhaps the Most Important Feature.