RE: SVG Accessibility

Doug Schepers wrote:
> 
> Hi, John–
> 
> >>>>>>>> 3. @longdesc is inappropriate for SVG graphics. Make
> >>>>>>>> the SVG DOM accessible instead.
> 
> 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; 

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

Well, FWIW, your statement sounds a lot more balanced to my ears. I bristle at the use of the word "inappropriate", as sometimes it might be wholly appropriate as one of "more than one" techniques that authors can use. 


> For other uses
> of SVG, as I mentioned, it's irrelevant.
> 
> >>
> >> 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".

While I must accept the truism of that statement, one thing that the entire @longdesc discussion has surfaced is that for any element or attribute to succeed, to see, gain and retain "support", is the crucial need of author awareness. Support without usage becomes complex: for example you yourself note that adding <title> and <desc> to SVG in Illustrator is "...not absolutely intuitive to get to this dialog, nor is it part of a typical workflow..."

Thus, to my mind, for real "support" - or more accurately "success", author awareness is key.

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

Question: was the <desc> content text that the user could access "on-demand", or was if simply delivered as part of the screen flow?  

One of the key aspects of @longdesc, as currently supported, is the ability for the end user (of screen reading technology) to GET the longer text, or skip past it. This is unlike aria-describedby content, which is delivered as part of the flow, whether or not the end user needs or wants the content. If that content is a sentence, the impact might not be that significant: if it is multiple paragraphs worth of content (describing a very complex infographic for example) then that has a real impact on the page's usability and usefulness to the non-sighted user.

> 
> 
> I couldn't find evidence of Firefox support for @longdesc.

We have "weak" support in Firefox. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=877453

There are other aspects of Firefox support that remain unresolved, due I believe in part to a lack of understanding by the Mozillian assigned to shepherd this through the system. I and others continue to work (and pester <smile>) David Bolter on the missing pieces.


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

Great Post Doug - thanks for that. And descibler? I need to spend some time with that but woot woot to start!


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

We chatted about that briefly last time we spoke in person, and I agree. I do want to reiterate the "selectability" requirement however - the user's ability to choose to hear or not hear the longer textual description on-demand (versus what I call "force-fed") - this is a big deal.

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

Well, it all depends on how you are measuring that support. For the primary targets (non-sighted screen reader users) we have very good if not universal support today (still missing VoiceOver for example). For sighted users, we have a combination of native support and extensions/plugins that expose the URL that is the long description: what we lack is elegant native browser support for all users.

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

See my explanation above. By support, what we (I?) mean is having the following characteristics:

1) No visual encumbrance
It must be possible to provide a description for an image without forcing the description to be rendered on the page.

JF: We have this in Spades. 
(More complicated is how this interacts when sighted users need/want to know about the existence of longer descriptions. There, we likely need *some* form of visual notification (screen readers do announce the presence, even if there is no actual text in the document), and via different forums I have suggested that it would likely be a user setting that could be toggled off or on, with a default of off. This would respect the primary "no visual encumbrance " unless the user chose to over-ride that setting.)

2) Structured Markup
It must be possible to include rich markup (e.g. HTML5) in the description of the image.

JF: We have support for this, as it is how @longdesc has been specced since 1999.

3) Inline
It must be possible to associate a description in the body of a page with an image in that page.

JF: @longdesc can reference either an external URL or a named anchor, and for screen readers and keyboard only users this works fine.

4) Reuse
It must be possible to re-use a single description for multiple occurrences of an image.

JF: Because @longdesc can reference a discrete URL, we have full support here.

5) Maintenance
It must be simple to maintain a library of images and descriptions for dynamic assembly, or dis-assembly and re-assembly, of content.

JF: Related to #4 - full support exists.

6) Discoverability
It must be simple for a user agent to automatically discover a description provided for a given image.
A user should be able to determine that there is a description available for a given image.

JF: this is where things break down. For *most* (but not all) screen reader "user agents", the presence of the longdesc attribute (and it's resource) are announced by the voice engine (or Braille output), and thus to the end user. However, without the use of some form of Assistive Technology, the cognitively challenged user (for example) is not being informed of the presence of the additional resource that is the longer description. So here we can only claim partial support - support for one user-group out of many, dependant on Assistive Technology tools used. There are browser extensions and plugins available that can add this functionality to certain browser "user agents", but they are third-party tools that vary in complexity (from usage to installation). I noted earlier that we still have some issues with Firefox support, and the discoverability problem remains the big one there.

7) Optional consumption
A user must be able to choose not to read the long description of a given image.

JF: I have previously mentioned this as well, both as a statement regarding aria-describedby, as well as a question regarding your proposed test of blob text versus longdesc text. However, whether using a screen reader that supports @longdesc, or using a third-party plugin, we generally have this support with @longdesc.

8) Simple return
A user must be able to return from the description to the image.

JF: Full support

9) Backwards Compatibility
It should be possible to use existing tools and techniques to associate an image with its description.

JF: this is one of the reasons why I also asked about authoring tool support for accessible SVG. I am pleased to hear that it exists, and is getting better.

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

LOL, well I don't see it as a competition (unless of course that competition will spur on better support for accessibility in both technology solutions <smile>). Suffice to say we have some support for both technologies, with room for improvement in both camps.

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

So, again, if we were discussion the accessibility of SVG, then I would concur. We are instead discussing the @longdesc attribute, and whether or not it is "appropriate" to use it with SVG. Under some contexts, I believe the answer is yes, and I am loathe to have the specification suggest otherwise. 

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

At the risk of beating the horse to death, I agree. I never intended this to be a discussion about SVG accessibility. 

It is (or at least was) a thread that started around the HTML5 Image Description Extension (longdesc) specification, and a comment directly related to the suitability and "appropriateness" of using @longdesc when <img> calls an SVG image (as opposed to PNG, GIF, or JPG). It is about feedback that to my mind and ears is an attempt to weaken the attribute by suggesting that it is flawed and "inappropriate" to use. 

The attribute isn't flawed, the support from some corners is lacking. Rather than tossing out the attribute, I argue we should encourage the user-agent developers to finish the job, and provide the support the spec calls for. When that happens, then we can properly gauge how appropriate, useful and successful @longdesc really is. Until that time, any language that seeks to weaken the specification seems (at least to me) as a move to avoid providing that support. (i.e. "If enough people are persuaded to not use @longdesc, we won’t need to support it going forward")

JF

Received on Thursday, 5 September 2013 05:50:54 UTC