Re: SVG Accessibility

Hi, John–

On 8/15/13 5:02 PM, John Foliot wrote:
> Doug Schepers wrote:
>>
>> (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.
>
> Agreed. It feels very, uhm, biased to my ears. (But then again, I
> also freely admit my own bias as a pro-longdesc advocate).

Just to be clear, James' claim doesn't sound biased to me, I just wasn't 
sure of its accuracy. James reports that the SVG DOM is exposed to AT 
for most uses of SVG, including <img>, in WebKit at least; if this is 
true, I don't think @longdesc is strictly necessary for <img>, though I 
guess it's not necessarily harmful, and sometimes useful. For other uses 
of SVG, as I mentioned, it's irrelevant.


> The real point being that the suitability of @longdesc is conditional
> on a lot of other factors, factors which should in my opinion be
> better addressed in authoring guides versus the actual specification.
> The answer is a lot less black and white than some would suggest.
>
>>>> 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":
>
> Support is a multi-definition term here. There is user-agent support,
> there is authoring agent support, and then there is author awareness.

Author awareness, while useful and essential, is not "support".


> Doug, I've not tested SVG accessibility support any time recently,
> but the last time I did check it was uneven across browsers and AT.
> That may be getting better, but we have no documented proof of such
> (as even yourself have noted).

This is why I've suggested we defer making any statements about it until 
we have solid evidence.

My own testing shows that any text or metadata (title, desc) in an SVG 
that is inline in HTML will be read out by all screenreaders I've seen 
tested (i.e., ChromeVox, NVDA, VoiceOver, JAWS).

Further support is still unclear.


> Conversely, support for @longdesc, while still not universal, has
> existed in JAWS for a number of years, is now supported by NVDA as
> well as a few other screen readers, and the state of browser support
> is moving forward (with Firefox's recent addition of @longdesc
> support, and the advances that Dominc Mazzoni is shepherding in
> Blink/Chrome).

I don't like that word, "conversely". It implies that @longdesc is 
better supported in screenreaders than SVG, which is not necessarily 
true. Let's stick to the facts, please.

I couldn't find evidence of Firefox support for @longdesc. The only 
thing I find is a Bugzilla bug [1] that was recently reopened, but has 
the status "Assigned To: Nobody; OK to take it and work on it"; this 
isn't support, but maybe I'm missing something? Are there tests for 
@longdesc, and an implementation report?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=854848


> Further, most editing tools today provide built in resources for
> creating the @longdesc linkage to the image, as well as often
> providing the means to author that long description easily.  See:
> http://john.foliot.ca/wysiwyg_longdesc/ for an overview of that
> support.
>
> Can you also suggest that SVG authoring tools have the same or
> similar levels of support for ensuring the creation of accessible
> content? (Personally I've only played with Inkscape, and saw nothing
> there that would lead me to believe that this type of support
> existed, but note that I used the word "played"). SVG gurus like you
> may still hand-code your SVG, but that does not scale :-)

This raised an interesting question in my mind, thanks! So interesting, 
that I halted my reply to your email a couple weeks ago, and launched 
into researching the matter.

The result is a blog post about the current state of authoring 
accessible SVG [2], which in turn got me interested in making a simple 
WYSIWYG authoring tool for making SVG's accessible, called Describler [3].

So, I can say with some confidence that there is at least one 
easy-to-use WYSIWYG editor for accessible SVG. :D (Oh, and Inkscape has 
pretty good support, too!)

[2] http://schepers.cc/authoring-accessible-svg
[3] http://describler.com/


>> * 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
>
> That’s a fairly significant issue wouldn't you say?

That really depends.

My chart example [4] sounds reasonably descriptive, even without any 
structured exploration.

I can imagine far more complex examples that would be difficult to 
comprehend without more navigability. I can also imagine much simpler 
ones that for which a simple single-paragraph description is adequate. I 
think @longdesc covers that same range, and I'd like to see results of a 
study that looks at the relative benefits of an inline "blob" of text 
from an SVG versus a structured but remote resource provided by @longdesc.


[4] http://schepers.cc/svg/accessibility/authoring/graph-desc.svg


>> * 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
>
> Right, but it remains a problem today.

As does @longdesc support, as you have mentioned yourself.


>> * 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
>
> Agreed.
>
> Based upon the above summary, I still stand behind the general notion
> that SVG Accessibility support is nowhere where it needs to be today.
> It is, overall, poor even if at the same time it is improving.

I don't draw the same conclusions from the same evidence.

I'm getting mixed messages from you about @longdesc; you seem to be 
claiming widespread support, but also mention that it's still missing 
support in some major browsers and possibly screenreaders.

So, I would say that even though SVG is a younger technology than 
@longdesc, it seems to have roughly equivalent levels of support. I'd 
need to see strong evidence to the contrary to believe otherwise.


> I also
> agree that like any other technology, we need to start using this
> more, so that more gets used (it is, and remains, the classic chicken
> and egg problem).

We agree there.


>>> 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,
>>> itis the
>>> support from user agents. (I can say the very same thing about
>>> theother way
>>> of making SVG accessible too - it isn't 'flawed', but without
>>> useragent support it is just words on a document).
>>
>> Well, if the document in question is an SVG document,
>
> No, the context here is specifically Specifications: the HTML5 Image
> Description Extension Spec (as well as the SVG 2 Spec I suppose).
>
> My overarching concern is that there is a suggestion coming forth
> that the spec somehow 'downplay' the use of the attribute it was
> written to advance (@longdesc), in favor of techniques and scenarios
> that are often no better or perhaps even not as good, all because of
> the legacy baggage and on-going "debate" over @longdesc.

The phrase "often no better or perhaps even not as good" seems kinda 
FUDy to me. In your enthusiasm for @longdesc, I think you may be 
inadvertently giving short shrift to SVG accessibility, and I'd prefer 
you were more careful about such statements.


> It may seem uncharitable as well, but the fact that the arguments are
> coming from a representative of the one browser that has not as yet
> indicated any notice of what they plan to do with this emergent
> specification is also causing me some personal frustration - the
> feedback feels less proactive and more defensive.

My read was that James is more interested in the best technical solution 
for users, rather than proscribing any given solution.


>>>> 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.
>
> While I have no cycles to lend to this Doug, I think it would be
> immensely useful to see this work happen. Not-knowing the
> state-of-the-state is a pretty serious problem.

Yes, we're working on it.


>> 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.
>
> Wholeheartedly agree!

Good! Then please stop dissing SVG accessibility. :D

It's not a competition between @longdesc and SVG. It's a matter of 
picking the right tool for the specific task.

Regards-
-Doug

Received on Thursday, 5 September 2013 12:11:42 UTC