JAWS with Internet Explorer and Firefox: it read the text of the figcaption but did not announce a figure and did not recognize that there was a graphic on the page. The JAWS key "G" to read the next graphic does not work because JAWS does not appear to recognize as a graphic. But adding alt text causes it to be recognized. So figcaption cannot replace alt yet for this behavior.
NVDA with Internet Explorer and Firefox: it read the text of the figcaption but did not announce a figure and did not recognize that there was a graphic on the page. The Jaws key "G" to read the next graphic does not work because NVDA does not appear to recognize as a graphic. But adding alt text causes it to be recognized. So figcaption cannot replace alt yet
Safari in Maverick: does not recognize the figure element and just says “group”, then an empty image and the text afterwards as if it was a paragraph as if there was no relationship between the legend and the graphic. It's hard to tell when the group ends. It just simply has a graphic without an alternative and then the next time the person arrows down they get the figcaption which doesn't appear to be a programmatic association except for the word “group” before the item.
Aviewer and IE:
Focus on Figure: this object does not show up on accessibilty tree
Focus on Flow content: no behaviour, acts like whatever element it is
Focus of figcaption: no accName... acts like a span
Aviewer and FF:
Focus on Figure: show up on accessibilty tree accName is figcaption, role is "grouping"
Focus on Flow content: no behaviour, acts like whatever element it is in the flow content
Focus of figcaption: the iAccessible name is figcaption, it says the relation is labelledby: value role is caption
What if the flow content is not an image?
it acts the same as a graphic in a figure
Not implemented in IE, does not report to an API ... lack of accessibility support
In firefox if the alt text is not present on the image then browsers and screen readers do not allow for focus to go onto the image nor do they tell you if it is an image. They just read the figcaption and assume the blind person is supposed to know what the object is.
If the figcaption is relied upon instead of alt text is no way currently in a screen reader to browse the images. images with alt can be moved to with "G"
Safari reads it as a group
Accessibility support can be improved but there several fundamental problems that will make it difficult for screen reader users to understand the figure element with the figcaption instead of an alt text.
I don't think we can assume that screen readers will begin to announce that there's a graphic inside the figcaption. Assumptions about longdesc got us into a lot of problems 10 years ago. I think reporting the figure as a role of group could be a problem that will be hard to resolve for screen reader users. Although it semantically is a group, it will take a while for SC users to understand that it in an image inside a group, sometimes and other times not.
I think this belongs in the larger discussion about alt text, and whether we should allow alternives to it. Because currently it is more confusing than aria-labelledby, aria label etc.
HTML5 does *not* allow figcaption as an alternative to alt
The HTML 5 spec only has one specific use case when the figcaption could replace alt text. And that is when the alt text is not available at the time of publication. It includes two important notes.
Note: Such cases are to be kept to an absolute minimum. If there is *even the slightest possibility* of the author having the ability to provide real alternative text, then *it would not be acceptable to omit the alt attribute*
Note: Since some users cannot use images at all (e.g. because they are blind) the alt attribute is only allowed to be omitted when no text alternative is available and none can be made available, as in the above examples. " source http://tinyurl.com/ox8uhys
I must confess that I was among those who thought HTML5 said the <figcaption> element was freely interchangeable with the ALT inside a <figure> element, even though the limitation is spelled out in the document in two places.
HTML5 provides no basis for a WCAG Sufficient technique on this. I think this will also help inform the greater discussion around F65. Because I believe most of us thought that there already was an alternative to ALT text allowed in HTML 5 which set a precedent. Any discussion we have about allowing substitutes for ALT, (aria-labelledby, aria-label ...) will have to stand on their own merits without a precedent in HTML 5.