E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 22 (In chronological order)

From: Birkir R. Gunnarsson
Date: Mon, May 07 2012 9:43AM
Subject: Screen reader interpretations of images in text (not part of a link)
No previous message | Next message →

Oh yea wise ones.

I was asked whether having a widespace inside the alt tag for an image
would cause screen readers to read it.
For this I cooked up a minor test. The answer to this is that Jaws
didn't but NVDA does with FF10 at least.
But along the way I discovred something else that really surprised me
Neither Jaws nor NVDA (tested with FF10 and IE9) indicates the
presence of an image in a webpage when it is missing an alt tag (see
example one in the attached document).
Inother words.
If you insert an img tag with a src attribute, it is treated by both
Jaws and NVDA as if it had an empty alt attribute.
For some reason I always thought that screen readers should indicate
the presence of the graphic and read the path or filename of the image
file.
I know they do that when the img is inside of an anchor tag, but was
surprised to see that they do not when the image is inserted by
itself.
Is this something everybody knows and I just discoverred?
Is this best practice for images (seems to me that users may want to
know about images in text even if people have forgotten to indicate
that they are decorative by setting the alt tag to ""), or is there a
coding error in this document somehow (hand coding HTML is something I
need to practice honestly, but I see no problem with the file, other
than I did not specify a layout for the imges).
Cheers
-B

From: Angela French
Date: Mon, May 07 2012 10:04AM
Subject: Re: Screen reader interpretations of images in text (not partof a link)
← Previous message | Next message →

>Is this something everybody knows and I just discoverred?
>-B

I always thought that screen readers would read the image filename in the absence of a specified alt attribute as well. And I thought that an alt attribute set to empty quotes, would ignore the image altogether. (My experiences comes from what I read).

Angela French

From: Tony Olivero
Date: Mon, May 07 2012 10:11AM
Subject: Re: Screen reader interpretations of images in text (not partof a link)
← Previous message | Next message →

>Is this something everybody knows and I just discoverred?
>-B

I can only speak to JAWS, because I know it best. Default behavior on the
web is to read "tagged images" and ignore untagged ones unless there is an
anchor around it. However, best practice in coding should still be to set
alt="" if the image is to be suppressed.

Ifyou press INSERT+V you can locate "Graphics, show [value]" and change the
behavior with the SPACE key.

Tony

From: Birkir R. Gunnarsson
Date: Mon, May 07 2012 10:12AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

To clarify
setting alt to "" (without widespace) causes all screen readers I have
tested to ignore it.
The problem crops up if you put widespace inside the quotes (NVDA
recognizes the picture and reads "graphic", I did not indicate it in
the attached file, I may expand upon this and create a table of screen
readers and browsers with responses).
But if alt text is absent altogether, that's the surprising thing, and
I thought, looking at WCAG, that screen readers should read the
filename of the image file or at least add the word "graphic" to
indicate the presence of an image.
I use all default settings btw, except setting Jaws verbosity to intermediate).


On 5/7/12, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
>>Is this something everybody knows and I just discoverred?
>>-B
>
> I always thought that screen readers would read the image filename in the
> absence of a specified alt attribute as well. And I thought that an alt
> attribute set to empty quotes, would ignore the image altogether. (My
> experiences comes from what I read).
>
> Angela French
> > > >

From: Jared Smith
Date: Mon, May 07 2012 10:37AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Paul J. Adam
Date: Mon, May 07 2012 10:41AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

Hi Birkir, VoiceOver reads the image with no alt text, it reads the filename. VO also reads the image with a space in the alt, reads "space image". It skips over the image with alt="" (null) and it is not navigable when switching to Images in the web rotor. There is a setting on iOS and OS X to navigate images: Always, With descriptions, or Never.

Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter

From: Steve Faulkner
Date: Mon, May 07 2012 12:34PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Mon, May 07 2012 12:59PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Jared Smith
Date: Mon, May 07 2012 1:29PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

On Mon, May 7, 2012 at 12:34 PM, Steve Faulkner wrote:

Thanks for chiming in Steve. I knew if I was wrong that you'd set me straight.

> success or failure techniques are not normative [1]

Of course. Though the intention is that if a page has a failure, it
would rarely be conformant. In this case, assuming HTML5 remains as
is, it seems the failure could simply be updated to not require the
alt attribute if the alternative text is provided elsewhere.

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

I guess this has changed then. Or maybe I had just misinterpreted it.
This is very good to know and is more restrictive than I had thought.

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

It really is a double-edged sword. If you flag them as errors, it may
promote accessibility. Or it may simply encourage authors to add null
or bogus alt attribute values (which suggest an image alternative
where none is present) simply to generate valid HTML. Admittedly, this
is the current situation for HTML <5, so I wouldn't really expect
things to change much.

> I provide
>  detail and examples of this and a bridging technique (until
> figure/figcaption is better supported) in section 3.12

To me, it seems that it would be better to omit the alt attribute and
<figcaption> altogether. In the case of unknown alternative text, any
approach that utilizes alt or figcaption suggests that a text
alternative is present, when in fact they do not contain an
alternative at all but instead contain a placeholder for that
alternative. This approach uses the alt attribute for something other
than an alternative, which seems wrong to me. It suggests, "alt and/or
figcaption present the image alternative text, except for when they
don't, so good luck figuring out if they actually present an
alternative or not."

Allowing the absence of the alt attribute altogether could be
absolutely clear - the image is inaccessible and does not have a known
alternative. There's no ambiguity or burden on the user to
differentiate between true alternative text and something else that is
currently in the same place the alternative would go if it were known.
Knowing definitively that something is inaccessible can be quite
useful. AT could try to do something useful with the image.
Additionally, automated accessibility validation tools could easily
flag such images as inaccessible. If the alt and/or figcaption
technique you provided was implemented when the alternative is not
known, there would be no way to automatically differentiate them from
other accessible images.

Please clarify if I am still misunderstanding this.

Jared

From: Steve Faulkner
Date: Mon, May 07 2012 1:46PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Ryan Hemphill
Date: Mon, May 07 2012 3:40PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Benjamin Hawkes-Lewis
Date: Mon, May 07 2012 4:04PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

T24gTW9uLCBNYXkgNywgMjAxMiBhdCAxMDo0MCBQTSwgUnlhbiBIZW1waGlsbAo8cnlhbmhlbXBo
aWxsLmVtYWlsQGdtYWlsLmNvbT4gd3JvdGU6Cj4gMiBjZW50cyBvbiBhIHRlY2huaWNhbCBub3Rl
Ogo+Cj4gSSdkIGxpa2UgdG8gbWVudGlvbiB0aGF0IGFyaWEtbGFiZWwgaXMgKGF0IGxlYXN0IGZv
ciBub3cpIGEgYmFkIGlkZWEgd2hlbgo+IGl0IGNvbWVzIHRvIFZvaWNlT3Zlci4gwqBJJ3ZlIHNl
ZW4gY2FzZXMgd2hlcmUgdGhlcmUgaXMgYSBodWdlIGFuZCB1Z2x5IGxhZwo+IHRpbWUgLSBJIGRv
bid0IHJlY29tbWVuZCBpdC4KClNlZW1zIG9kZC4gRG8geW91IGhhdmUgYSB0ZXN0IGNhc2UgdGhh
dCBpbGx1c3RyYXRlcyB0aGlzPwoKLS0KQmVuamFtaW4gSGF3a2VzLUxld2lzCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClRvIG1hbmFnZSB5b3VyIHN1YnNj
cmlwdGlvbiwgdmlzaXQgaHR0cDovL2xpc3Qud2ViYWltLm9yZy8KQWRkcmVzcyBsaXN0IG1lc3Nh
Z2VzIHRvIHdlYmFpbS1mb3J1bUBsaXN0LndlYmFpbS5vcmcK

From: Paul J. Adam
Date: Mon, May 07 2012 5:20PM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

aria-label is working with VoiceOver on iOS 5.0.1 and OS X Lion.

aria-label image example

http://yaccessibilityblog.com/examples/images/image-aria-test.html

Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter

On May 7, 2012, at 5:04 PM, Benjamin Hawkes-Lewis wrote:

> On Mon, May 7, 2012 at 10:40 PM, Ryan Hemphill
> < = EMAIL ADDRESS REMOVED = > wrote:
>> 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.
>
> Seems odd. Do you have a test case that illustrates this?
>
> --
> Benjamin Hawkes-Lewis
> > >

From: Steve Faulkner
Date: Tue, May 08 2012 3:22AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

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

From: Ryan Hemphill
Date: Tue, May 08 2012 8:20AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

I haven't been investigating Lion yet, and maybe it's working okay in that
OS. I will look for my example, but even if I don't find it right now
(very busy) just be aware that it ought to be tested to make sure it isn't
occurring.

aria-labelledby, on the other hand, works just fine in VoiceOver. Of
course, that attribute will kill the IE browser completely in Windows 7 -
and that testing has been very, very consistent. The way around that one
is to use aria-labeledby (one 'l' instead) and you're okay. Interestingly,
that format works fine in FF as well as the NVDA testing of both browsers
as well. It seems that the screen reader companies took into account the
fact that people might screw up the spelling and made accommodations for
that issue.

And with that, I return to the grindstone. Happy hunting.

- Ryan.

From: Steve Faulkner
Date: Tue, May 08 2012 8:30AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

hi jared,
you wrote:

"It really is a double-edged sword. If you flag them as errors, it may
promote accessibility. Or it may simply encourage authors to add null
or bogus alt attribute values (which suggest an image alternative
where none is present) simply to generate valid HTML. Admittedly, this
is the current situation for HTML <5, so I wouldn't really expect
things to change much."



if this were the case it would be expected that there would be a
correlation between high number of alt="" and low HTML errors or conforming
pages.
I have done some ad hock data collection from the top 10000 web sites data
[1] i collected recently and have not found any correlation so far.


"Allowing the absence of the alt attribute altogether could be
absolutely clear - the image is inaccessible and does not have a known
alternative. There's no ambiguity or burden on the user to
differentiate between true alternative text and something else that is
currently in the same place the alternative would go if it were known."


The idea that an img missing an alt can equal an informative image for
which there is no text alternative provided would only work IF the page was
other wise conforming HTML5. This does not appear to be the case.


Note that figcaption is different as the figcaption element has a defined
semantic (IA2 role of caption as implemented in firefox)) and the figure
element will be getting a role in ARIA 1.1 (cy=urrently implemented as the
more geenric group role in firefox). what this means in the case of an
image missing an alt is that if its in a figure you can be fairly certain
it is a meaningful image. The caption is the label for the figure and SRs
should announce the presence of the image even though it does not have an
alt (becuase its inside a figure element)

<figure>
<img>
<figcaption>image 1<figcaption>
</figure>

i go into more details about this in HTML5 Accessibility Chops: the figure
and figcaption elements [2]

[1] http://www.paciellogroup.com/blog/?sÚta+for+the+masses
[2]
http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/


regards
steve

On 7 May 2012 20:29, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, May 7, 2012 at 12:34 PM, Steve Faulkner wrote:
>
> Thanks for chiming in Steve. I knew if I was wrong that you'd set me
> straight.
>
> > success or failure techniques are not normative [1]
>
> Of course. Though the intention is that if a page has a failure, it
> would rarely be conformant. In this case, assuming HTML5 remains as
> is, it seems the failure could simply be updated to not require the
> alt attribute if the alternative text is provided elsewhere.
>
> > "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.
>
> I guess this has changed then. Or maybe I had just misinterpreted it.
> This is very good to know and is more restrictive than I had thought.
>
> > 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.
>
> It really is a double-edged sword. If you flag them as errors, it may
> promote accessibility. Or it may simply encourage authors to add null
> or bogus alt attribute values (which suggest an image alternative
> where none is present) simply to generate valid HTML. Admittedly, this
> is the current situation for HTML <5, so I wouldn't really expect
> things to change much.
>
> > I provide
> > detail and examples of this and a bridging technique (until
> > figure/figcaption is better supported) in section 3.12
>
> To me, it seems that it would be better to omit the alt attribute and
> <figcaption> altogether. In the case of unknown alternative text, any
> approach that utilizes alt or figcaption suggests that a text
> alternative is present, when in fact they do not contain an
> alternative at all but instead contain a placeholder for that
> alternative. This approach uses the alt attribute for something other
> than an alternative, which seems wrong to me. It suggests, "alt and/or
> figcaption present the image alternative text, except for when they
> don't, so good luck figuring out if they actually present an
> alternative or not."
>
> Allowing the absence of the alt attribute altogether could be
> absolutely clear - the image is inaccessible and does not have a known
> alternative. There's no ambiguity or burden on the user to
> differentiate between true alternative text and something else that is
> currently in the same place the alternative would go if it were known.
> Knowing definitively that something is inaccessible can be quite
> useful. AT could try to do something useful with the image.
> Additionally, automated accessibility validation tools could easily
> flag such images as inaccessible. If the alt and/or figcaption
> technique you provided was implemented when the alternative is not
> known, there would be no way to automatically differentiate them from
> other accessible images.
>
> Please clarify if I am still misunderstanding this.
>
> Jared
> > > >



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

From: Steve Faulkner
Date: Tue, May 08 2012 8:32AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

hi Ryan,

you wrote:

"Of
course, that attribute will kill the IE browser completely in Windows 7 -
and that testing has been very, very consistent. "

can you provide more detail on this?

regards
stevef

On 8 May 2012 15:20, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:

> I haven't been investigating Lion yet, and maybe it's working okay in that
> OS. I will look for my example, but even if I don't find it right now
> (very busy) just be aware that it ought to be tested to make sure it isn't
> occurring.
>
> aria-labelledby, on the other hand, works just fine in VoiceOver. Of
> course, that attribute will kill the IE browser completely in Windows 7 -
> and that testing has been very, very consistent. The way around that one
> is to use aria-labeledby (one 'l' instead) and you're okay. Interestingly,
> that format works fine in FF as well as the NVDA testing of both browsers
> as well. It seems that the screen reader companies took into account the
> fact that people might screw up the spelling and made accommodations for
> that issue.
>
> And with that, I return to the grindstone. Happy hunting.
>
> - Ryan.
> > > >

From: Steve Faulkner
Date: Tue, May 08 2012 8:41AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

I just checked with IE9 and windows 7 and JAWS 12 on this page:
http://www.html5accessibility.com/tests/form-labels.html

had no problems?


I would not suggest using the incorrect spelling "aria-labeledby" for the
attribute as a workable interoperable solution

regards
stevef

On 8 May 2012 15:32, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> hi Ryan,
>
> you wrote:
>
> "Of
> course, that attribute will kill the IE browser completely in Windows 7 -
> and that testing has been very, very consistent. "
>
> can you provide more detail on this?
>
> regards
> stevef
>
>
> On 8 May 2012 15:20, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I haven't been investigating Lion yet, and maybe it's working okay in that
>> OS. I will look for my example, but even if I don't find it right now
>> (very busy) just be aware that it ought to be tested to make sure it isn't
>> occurring.
>>
>> aria-labelledby, on the other hand, works just fine in VoiceOver. Of
>> course, that attribute will kill the IE browser completely in Windows 7 -
>> and that testing has been very, very consistent. The way around that one
>> is to use aria-labeledby (one 'l' instead) and you're okay.
>> Interestingly,
>> that format works fine in FF as well as the NVDA testing of both browsers
>> as well. It seems that the screen reader companies took into account the
>> fact that people might screw up the spelling and made accommodations for
>> that issue.
>>
>> And with that, I return to the grindstone. Happy hunting.
>>
>> - Ryan.
>> >> >> >>
>
>


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

From: Léonie Watson
Date: Tue, May 08 2012 9:39AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

Steve Faulkner wrote:
"I just checked with IE9 and windows 7 and JAWS 12 on this page:
http://www.html5accessibility.com/tests/form-labels.html

had no problems?"

In case it's helpful, both examples using aria-labelledby work ok
with Jaws 13 and IE9 on Win7 64bit.


L.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve Faulkner
Sent: 08 May 2012 15:41
To: WebAIM Discussion List
Subject: Re: [WebAIM] Screen reader interpretations of images in text (not
part of a link)

I just checked with IE9 and windows 7 and JAWS 12 on this page:
http://www.html5accessibility.com/tests/form-labels.html

had no problems?


I would not suggest using the incorrect spelling "aria-labeledby" for the
attribute as a workable interoperable solution

regards
stevef

On 8 May 2012 15:32, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> hi Ryan,
>
> you wrote:
>
> "Of
> course, that attribute will kill the IE browser completely in Windows
> 7 - and that testing has been very, very consistent. "
>
> can you provide more detail on this?
>
> regards
> stevef
>
>
> On 8 May 2012 15:20, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I haven't been investigating Lion yet, and maybe it's working okay in
>> that OS. I will look for my example, but even if I don't find it
>> right now (very busy) just be aware that it ought to be tested to
>> make sure it isn't occurring.
>>
>> aria-labelledby, on the other hand, works just fine in VoiceOver. Of
>> course, that attribute will kill the IE browser completely in Windows
>> 7 - and that testing has been very, very consistent. The way around
>> that one is to use aria-labeledby (one 'l' instead) and you're okay.
>> Interestingly,
>> that format works fine in FF as well as the NVDA testing of both
>> browsers as well. It seems that the screen reader companies took
>> into account the fact that people might screw up the spelling and
>> made accommodations for that issue.
>>
>> And with that, I return to the grindstone. Happy hunting.
>>
>> - Ryan.
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>>
>
>


--
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
messages to = EMAIL ADDRESS REMOVED =

From: Bourne, Sarah (ITD)
Date: Tue, May 08 2012 10:14AM
Subject: Re: Screen reader interpretations of images in text (notpart of a link)
← Previous message | Next message →

We have seen "aria-labelledby" kill IE, but ONLY when it's used incorrectly. In both instances, it was using the ID of the tag it was in instead of the tag (and its content) it should have been referring to. IE apparently doesn't like circular arguments.

sb

Sarah E. Bourne
Director of Assistive Technology &
Mass.Gov Chief Technology Strategist
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd

From: Ryan Hemphill
Date: Tue, May 08 2012 11:55AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | Next message →

Ugh, this is killing me.

I was under the impression that I wasn't the only one noticing this, so it
seems that I shot my mouth off - however, I have seen a multitude of
occasions in my own work where the program was crashing from
aria-labelledby, as there was nothing else that I changed to create a fix.

I will research the exact cases where I see this happening, but I have run
into this problem so many times it has become a broken record for me. Any
time I crash JAWS/IE in Win7, it has ALWAYS been the existence of a
focusable aria-labelledby attribute.

I'll get back you on this. I'm sure I can track down an example - wouldn't
be surprised if it is javascript related at this point...

Ryan


On Tue, May 8, 2012 at 10:32 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:

> hi Ryan,
>
> you wrote:
>
> "Of
> course, that attribute will kill the IE browser completely in Windows 7 -
> and that testing has been very, very consistent. "
>
> can you provide more detail on this?
>
> regards
> stevef

From: Ryan Hemphill
Date: Tue, May 08 2012 11:56AM
Subject: Re: Screen reader interpretations of images in text (not part of a link)
← Previous message | No next message

Interesting point, Sarah - I'll include that in my research.

On Tue, May 8, 2012 at 1:55 PM, Ryan Hemphill
< = EMAIL ADDRESS REMOVED = >wrote:

> Ugh, this is killing me.
>
> I was under the impression that I wasn't the only one noticing this, so it
> seems that I shot my mouth off - however, I have seen a multitude of
> occasions in my own work where the program was crashing from
> aria-labelledby, as there was nothing else that I changed to create a fix.
>
> I will research the exact cases where I see this happening, but I have run
> into this problem so many times it has become a broken record for me. Any
> time I crash JAWS/IE in Win7, it has ALWAYS been the existence of a
> focusable aria-labelledby attribute.
>
> I'll get back you on this. I'm sure I can track down an example - wouldn't
> be surprised if it is javascript related at this point...
>
> Ryan
>
>
>
> On Tue, May 8, 2012 at 10:32 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:
>
>> hi Ryan,
>>
>> you wrote:
>>
>> "Of
>> course, that attribute will kill the IE browser completely in Windows 7 -
>> and that testing has been very, very consistent. "
>>
>> can you provide more detail on this?
>>
>> regards
>> stevef
>
>


--



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