Accessibility: Recommended Alt-Text Convention for Svg and Mathml

Accessibility: recommended alt-text convention for SVG and MathML?

After some digging, I found some somewhat official recommendations. Unfortunately, most are not functional at this point in time. Both the browsers and the screen readers have a lot of to implement before Math and SVG can be considered accessible, but things are starting to look up.

Disclaimer: the below recommendations are what I have gleaned over the past few months of coding. If something is dead wrong, please let me know. I will try to keep this up to date as browsers and AT software progresses.

MathML

Recommendation

Use role="math" along with an aria-label on a surrounding div tag (see docs). The addition of tabindex="0" allows screen readers to focus specifically on this element; this element's aria-label can be spoken using a special key shortcut (such as NVDA+Tab).

<div role="math" tabindex="0" aria-label="[spoken equivalent]">
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    ...
  </math>
</div>

Limitations/Considerations

Sketchy screen reader support on aria-label (and less importantly role="math").
Update: Relevant NVDA tickets regarding aria-label here and here.
Wrapping in div or span tag seems unnecessary since math is a first-class element in HTML5.
I found very little referencing the MathML alttext tag.
Update: this appears to be a DAISY-specific addition, described here.

References

http://www.w3.org/TR/wai-aria/roles#math
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0008.html
http://www.w3.org/TR/wai-aria-practices/#math

SVG

Recommendation

Use top-level <title> and <desc> tags together with role="img" and aria-label on the root SVG tag.

<svg role="img" aria-label="[title + description]">
  <title>[title]</title>
  <desc>[long description]</desc>
  ...
</svg>

Limitations/Considerations

As of February 2011, IE 9 beta reads all <title> and <desc> tags, which is probably undesirable. However, NVDA, JAWS, and WindowEyes will read the aria-label when the element also contains role="img".
If loading an SVG file (that is, not inline in HTML), the root-level <title> tag will become the browser page's title, which will be read by the screen reader.

References

http://lists.w3.org/Archives/Public/www-svg/2010Oct/0029.html
http://lists.w3.org/Archives/Public/public-html/2010Jun/0127.html
http://www.w3.org/TR/wai-aria/roles#img
http://www.w3.org/TR/wai-aria/roles#namecalculation

Alt tag possible for inline SVG?

You should use title element, not alt tag, to display tooltips:

<svg version="1.1" id="svg-header-filter" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="27px" height="27px" viewBox="0 0 37 37" enable-background="new 0 0 37 37" xml:space="preserve">
    <title>Hello world!</title>
    <path class="header-filter-circle" d="M17.796,0C7.947,0,0,7.988,0,17.838s7.947,17.787,17.796,17.787c9.848,0,17.829-7.935,17.829-17.783 C35.625,7.988,27.644,0,17.796,0z"/>
    <g>
        <path class="header-filter-icon" fill="#FFFFFF" d="M15.062,30.263v-9.935l-8.607-8.703h22.343l-8.744,8.727v5.029L15.062,30.263z M8.755,12.625l7.291,7.389 v7.898l3.025-2.788v-5.086l7.426-7.413H8.755z"/>
    </g>
</svg>

for chrome34: wrap graphics by g element and insert title element to this.

<svg version="1.1" id="svg-header-filter" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="27px" height="27px" viewBox="0 0 37 37" enable-background="new 0 0 37 37" xml:space="preserve">
<g>
    <title>Hello world!</title>
    <path class="header-filter-circle" d="M17.796,0C7.947,0,0,7.988,0,17.838s7.947,17.787,17.796,17.787c9.848,0,17.829-7.935,17.829-17.783 C35.625,7.988,27.644,0,17.796,0z"/>
    <g>
        <path class="header-filter-icon" fill="#FFFFFF" d="M15.062,30.263v-9.935l-8.607-8.703h22.343l-8.744,8.727v5.029L15.062,30.263z M8.755,12.625l7.291,7.389 v7.898l3.025-2.788v-5.086l7.426-7.413H8.755z"/>
    </g>
</g>
</svg>

HTML5 svg tag and alt attribute

SVG doesn't have an alt attribute, it uses a <desc> child tag instead.

<svg width="120" height="35">
  <desc>Stuff</desc>
  {{ STUFF }}
</svg>

Web Accessibility - Ensure alternative text is informative for image links (SVG Images)

My solution wasn't fun, but it did the trick. You can simply take the SVG tag and all it's content out of the A tag, and then use CSS to position it where it belongs, and it will pass the tool.. I wish there was a better way but I haven't found one. If you do know something I don't, please share it, it will be much welcomed. Thanks!

Final result that works:

<svg role="img" class="icon icon-large">
<title>Build a Long-Term Plan</title>
<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#icon-calendar"></use>
</svg>
<a href="/some-url-here/" class="some-class">
 <span>Build a Long-Term Plan</span>
</a>

What is the appropriate alt tag for an image where we only know that it was uploaded by a user?

The specification has exhaustive information about the alt attribute including a section Images whose contents are not known:

In some unfortunate cases, there might be no alternative text available at all, […] because the page is being generated by a script using user-provided images where the user did not provide suitable or usable alternative text (e.g. photograph sharing sites) […]
In such cases, the alt attribute may be omitted, but one of the
following conditions must be met as well:
The img element is in a figure element that contains a figcaption element that contains content other than inter-element whitespace, and, ignoring the figcaption element and its descendants, the figure element has no flow content descendants other than inter-element whitespace and the img element.
The title attribute is present and has a non-empty value.

(snip)

A photo on a photo-sharing site, if the site received the image with no metadata other than the caption, could be marked up as follows:

<figure>
  <img src="1100670787_6a7c664aef.jpg">
  <figcaption>Bubbles traveled everywhere with us.</figcaption>
</figure>

It would be better, however, if a detailed description of the important parts of the image obtained from the user and included on the page.

I am less concerned about SEO in this specific case than I am accessibility. I'm not sure what the best practice is and if having screen readers read out repetitive content could potentially be bad.

Make it easy for screen reader users to skip the section. Make use of <section> elements and <h1> and friends. That way when they get the announcement "Section: Customer photos", they can skip to the next heading.

Best Practice: ATAG

The best practice would be to acknowledge that your site is an authoring tool, as it allows creating content, and to conform to the Authoring Tool Accessibility Guidelines (ATAG).

This would mean (among others) that you

Make it possible to provide an alternative text for users that upload photos to Ensure that accessible content production is possible
Assist authors with managing alternative content for non-text content
Provide an error or warning if alt is missing, to Assist authors in checking for accessibility problems

Provide alt text in image with link, the link is in 2 different places in the same block content

Remove the aria-label on the div. It's useless on an non-interactive element, or worst can cause accessibility damages.
Images inside links must always contain an alt attribute when they are the only content within them

Once this is done, you may consider adding the aria-hidden="true" attribute to one of the links if you think those two links are repetitive. The other possibility is to use a javascript only solution for the click on the image which will avoid any keyboard related problematic. Because many people use keyboard navigation without using a screen reader.

You can also consider combining the image and the link

Alternative text for <span> element styled as icon to meet accessibility guidelines

Rather than thinking about meeting guidelines (I can't think of a specific one you would "fail" though just so you are aware) just think what makes the site easier to use / provides the best possible experience.

As we can't see the surrounding items we can't comment on whether an "L" makes sense in context.

As such the simplest thing would be to add an aria-label to the span. This will mean that a screen reader will actually read "low" rather than "l".

<span class="icon" title="Low" role="img" aria-label="low">L</span>

You may also want to say what item is "low" as part of the label if this span isn't part of a paragraph. aria-label="widget one stock is low".

As title is not very reliable for screen readers (and useless for people on touch devices) you might also consider having a key for sighted users that explains what L, M, H etc. mean (or whatever letters you use) and then you can do away with the title.

This will also greatly benefit mobile users (if the site is mobile friendly) who can't see the title attribute.

One adjustment

I realised after the answer was accepted I didn't cover the role="image" part.

That is probably not needed at all once you have the aria-label on it, especially if you use the longer form of the label aria-label="widget one stock is low" I suggested.

Yet again depends on your use case but I would be 80% confident in saying this is the case without seeing anything else.

This will also probably help when running automated accessibility tests as it won't complain about a missing alt attribute.

<span class="icon" aria-label="widget one stock is low">L</span> would be perfectly valid.

What is best practice (and legal) for product listing image alt text for accessibility?

Which method(s) are best for users?

Method 1 out of the options given is best.

Which method(s), if any, would NOT satisfy WCAG Level AA and therefor not comply with laws in the US, EU, etc.

None of them would fail WCAG as such.

However as you have pointed out 2 and 3 result in duplication of effort for keyboard users and links to the same location having different names, which is not a fail under any success criterion but is highly recommended.

Would the image in a Product Listing Page be classified as "decorative"?

Yes in scenario 1 and 4.

Expansion of the answers given

All 4 of the examples given would "pass" WCAG. However they offer very different experiences.

So the question is what things are we considering for accessibility?

The first is Keyboard operability. Examples 2 and 3, as you pointed out result in duplication of focus stops for the same item. So we should avoid them.

The second thing is link purpose. Yet again examples 2 and 3 are not great here as we have 2 links to the same place on the same page that have different accessible labels / text that assistive tech will use.

So we can rule out options 2 and 3 for best practices.

So what about options 1 and 4?

Well as the items are located within a hyperlink we want the link text (the accessible name for those links) to be descriptive of the product page we are going to visit.

As such option one would read: "link: Squeaky Fox Dog Toy" and the second link would read "link: (image) Red fox stuffed dog toy with white braided rope arms, Squeaky Fox Dog Toy"

The second option results in duplication of information so is not as desirable as the first option.

So we land on option 1.

The only consideration you now have is whether that link text describes the product sufficiently. Now if you sold multiple dog toys (different product types) then you need text that describes them as such i.e. "plastic dog toys" and "fluffy dog toys".

If you sell different coloured products and they all had their own page (so you don't have a colour picker on the end page, they are listed as separate items) then you would need to describe the colour there too. "Red fluffy dog toy", "blue fluffy dog toy".

Essentially you need to provide enough information that each product link is easily identifiable as to where it leads (the purpose of the link itself).

This is where judgement comes into play, provide enough information to describe the product generally in a unique way on the page, not so much information that browsing that page becomes problematic due to 100 products with 200 word link text.

So in the example given the "balance" would be something like "Red fox stuffed dog toy", and then describe the appearance in far more detail on the product page, wither in the description or in the product image alt attributes.

Option 5 - if you don't have text at all.

It is worth noting that the last option for a product page is no text at all. Just an image inside a link. The following is also valid HTML and accessible as the alt text will be used as the link text (not if an image contains any text at all that should all appear in the alt attribute).

<a href="/my-product">
    <img src="image.jpg" alt="Red fox stuffed dog toy with white braided rope arms">
</a>

Extra powers

Sometimes you may not to be able to control the content of the link itself (maybe alt text is managed centrally or you have a description for each item as well that would make the link text far too verbose.)

In that case you can fall-back to WAI-ARIA (always a last resort) and provide the link text with that:

<a href="/my-product" aria-label="DESCRIPTION THAT OVERRIDES ALL CONTENT">
    <img src="image.jpg" alt="Red fox stuffed dog toy with white braided rope arms">
    <span class="product-name">Squeaky Fox Dog Toy</span>
    <p class="long-and-verbose-description">Way too much information for a link that is overridden by the aria-label</p>
</a>

Relevant Guidance

combining link text and adjacent images
Technique for associating links with the heading they fall under (for if you split products into sections on the page

Accessibility: Recommended Alt-Text Convention for Svg and Mathml