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

Doug Schepers wrote:
> 
> 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.

Agreed. It feels very, uhm, biased to my ears. (But then again, I also freely admit my own bias as a pro-longdesc advocate).  

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

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

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



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


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


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


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

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. 

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.


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


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


Cheers!

JF

Received on Thursday, 15 August 2013 21:05:25 UTC