SVG Accessibility (was: Call for Review: HTML5 Image Description Extension (longdesc) Last Call)

Hi, folks–

(Splitting into a separate thread on SVG accessibility and the 
suitability of @longdesc with SVG.)

On 8/15/13 1:07 PM, John Foliot wrote:
> James Craig wrote:
>>>>>> 3. @longdesc is inappropriate for SVG graphics. Make the SVG DOM
>> accessible instead.

This may be a misleading statement. We have to look at different 
scenarios to assess its truth value.


If an SVG is referenced from an <img> element, or as a CSS background, 
its DOM is not available, so using @longdesc (or @title or @alt) on the 
referencing element is appropriate.


If SVG is referenced from an <iframe>, <embed>, or <object> element, 
availability of its DOM is ambiguous, and not consistent across 
browsers. That needs to be specified, tested, and fixed (IMO, it should 
be available). So, pragmatically speaking, using @longdesc (or @title or 
@alt) on the referencing element is appropriate.


If SVG is inline in HTML, or is in a standalone file, @longdesc is 
simply not available (except on containing elements, like <div> or 
<section>). SVG has no @longdesc attribute available on its elements, 
nor should it; that's the role of the <title> and <desc> elements, 
available as child elements on every graphics or container element in 
SVG, including the SVG root. So, if you want a long description of your 
graphic, put it as content of the root's <desc> element.


So, I would refine this generalization to: "@longdesc is irrelevant to 
SVG itself, but may be applied to HTML elements that reference SVG as an 
image."


I'll address the state of the art in SVG accessibility below...

>>> You don't appear to have answered the comment on SVG, which is that I
>> agree in principle (and agreed to co-chair the Accessible SVG task
>> force to try and get some motion on what is currently a sorry story in
>> practice), but in practice that actually fails to help most people who
>> need to use your content *today*.
>>
>> I'm not sure I understand the comment. Is it that longdesc is better
>> because it's been around longer even though it's not well implemented?
>> AFAIK there is nothing stopping an author from using longdesc in HTML4
>> on an accessible SVG image.
...
>> This would validate as well as being
>> accessible to systems that supported either longdesc or SVG
>> accessibility.
>>
>> That said, if an SVG document can be made reasonably accessible, I
>> would object to the spec condoning longdesc as an easy alternative to
>> making the SVG accessible natively. IOW, using both is okay, but using
>> only longdesc instead of native SVG accessibility is not okay.
>
> Given the poor state of support for the other ways of making SVG accessible
> today, why is the "only longdesc" solution not OK?

It's not accurate to claim that the state of SVG accessibility is poor 
(in fact, it may be as good as the current state of support for 
@longdesc); it is accurate to say that support for SVG accessibility is 
uneven, and that the precise current state is unknown.

Informal testing across a variety of browsers and AT overall seems to be 
that SVG support is "okay":

* inline SVG in HTML is generally treated, at worst, as text content in 
an "unknown element", so the screen reader will read out the contents of 
<text>, <tspan>, <textPath>, <title>, and <desc>  elements... but only 
in document order, not in a structured way; links (<a> elements), are 
typically focusable, keyboard accessible, and navigable

* the DOM of referenced SVG (external files from <iframe>, <embed>, and 
<object> elements) is typically not available, even by the same 
browsers/AT; I think this should be a simple fix, and should be treated 
the same way that HTML in an <iframe> is treated

* again, the SVG DOM in <img> or CSS backgrounds is not exposed, by design

* in some AT that do "incidentally" read SVG content, the content of the 
<style> element in SVG seems (by some reports) to be read out, which is 
clearly a bug


> It may not be optimum,
> but it is a far sight better than nothing, and again, the way this is being
> phrased has the appearance of suggesting that @longdesc is a flawed
> mechanism.
>
> Let's be 100% clear here, it is not the attribute that is flawed, it is the
> support from user agents. (I can say the very same thing about the other way
> of making SVG accessible too - it isn't 'flawed', but without user agent
> support it is just words on a document).

Well, if the document in question is an SVG document, and not just a 
spec, then "words on a document" is often good enough, in a 
well-authored document. It's as good as @longdesc support would be.

It's worth pointing out that accessible text content directly in an SVG 
document is better than @longdesc content referring to that SVG, because 
internal content would travel with the SVG no matter where it's used.


>>>>> In the case of SVG we currently have a disconnect between theory
>> and reality. Although my text on SVG accessibility is (after more than
>> a decade) pretty solid on how to make the DOM accessible, in practice I
>> believe that is only useful for the relatively small proportion of
>> users who have VoiceOver.
>>
>> Doug Schepers says this works pretty well with NVDA, too. Maybe JAWS?
>
> Do we have any documented test results?

Few, and nothing formal.  Informally, I've seen it working for inline 
SVG for NVDA, JAWS, VoiceOver, and ChromeVox, but didn't do extensive 
testing.

That's why I recently formed the SVG Accessibility Community Group, 
which I encourage interested people to join and participate in:
  http://www.w3.org/community/svga11y/

Read more here:
  http://www.w3.org/community/svga11y/2013/08/15/roadmap/


I don't think it's useful to make claims (pro or con) about the state of 
SVG accessibility support without backing them up with experience, 
evidence, and testing. I'm only reporting here what I've seen; there may 
be other scenarios or environments where the reality is different, which 
is why we need comprehensive testing. Writing spec language based on 
guesses about SVG support seems counterproductive.

Regards-
-Doug

Received on Thursday, 15 August 2013 19:45:51 UTC