RE: SVG Accessibility (and Longdesc / HTML Image Description Extension spec)

At Chaals' request, an off list thread is being brought back into the public list. Doug and James, I hope you do not mind.

> Doug Schepers wrote:
> 
> Hi, folks–
> 
> First... why is this off-list? All of this seems relevant.
> 
> Questions and comments inline...
> 
> On 9/4/13 4:21 PM, James Craig wrote:
> >
> > On Sep 4, 2013, at 12:44 PM, John Foliot <john@foliot.ca
> > <mailto:john@foliot.ca>> wrote:
> >
> >> James Craig wrote:
> >>>
> >>> This was my point exactly. Even if @longdesc ends up being a
> >>> great hammer, not every image is a nail. SVG, iframes, and even
> >>> regular links are great tools to use in other circumstances, and
> >>> I want to make sure the image description draft acknowledges that.
> >>
[Foliot]
> >> I think that part of the problem is that the discussion around the
> HTML5
> >> Image Description extension spec strayed into SVG territory, in part
> >> because
> >> SVG *can* be referenced via the <img> element. While I do agree that
> it is
> >> important to note that there are other ways of using SVG in a
> >> document, and
> >> that there are also other ways of making SVG accessible, I think
> we're
> >> missing an important point, which is that this is not a discussion
> about
> >> "the accessibility of SVG", but rather how to provide a longer text
> >> description for <img>.
> >
[Craig]
> > How is this off-topic? If all images could describe their content
> > accessibly, longdesc would be entirely obsolete. PNG and TIFF can
> store
> > additional alternative text metadata in the file, too.
> 
[Schepers]
> Do you know what the specifics of this would be? What metadata format,
> which fields, and what browsers or screenreaders would support
> retrieving this information?

One of the use-cases/requirements that @longdesc supports is the ability to support Structured (HTML) content. This is a RFC 2119 MUST requirement. Are you aware of any metadata formats that meet that criteria? 

As well, while this is certainly an interesting idea (which *has* been discussed in the past - notably by David Singer), I am unaware of any browser or Assistive Technology that natively extracts embedded metadata from an image today - the closest I can think of is when Flickr exposes EXIF data (a metadata format that is not supported in JPEG 2000, PNG, or GIF formats), and which is raw data that is then formatted by the Flickr template page. One for the futures column, but not viable today.

[Schepers] 
> If this is viable, I could probably add this functionality to
> Describler, as well.
> 
> I had thought of image-stored metadata a while back, but assumed there
> were barriers to this approach. Implementation support aside, what
> use-cases exist for @longdesc that wouldn't be solved by image-stored
> metadata?
> 
> I guess one such case is that while an image-stored description would
> be
> generic for the same image in every instance, 

Exactly right. Currently we have this problem with content management systems that allow users to upload images and associate @alt text (and even sometimes @longdesc content) that is all stored in databases but as separate data fields - the problem is that the image may in fact be a multi-use image, or targeted towards different user-groups who would have different longdesc requirements. There is in fact an advantage to *not* having descriptions and alt texts embedded in every image.

[Schepers]
> sometimes authors might
> want to customize the image description for a specific instance of use,
> e.g. the image description is "A frozen-over lake in winter, at
> sunrise,
> with snow and icicles on the surrounding tree limbs", an author might
> want to provide more poetic description on one page (e.g., "An icy lake
> that feels like loneliness") and prosaic on another (e.g. "Mitchell
> Lake, Wisconsin, in January"). However, that doesn't feel like a
> deal-breaker... that could even be alt text, or better yet, a caption
> or
> other visible text.

Yes, a caption or other on-screen text could, and perhaps even should be the best choice here, but sometimes there are layout and "marketing" restrictions that prevent content authors from always doing "the best thing", and so having viable alternative solutions is always a good thing in my book. I focus on the outcomes as much as the ways and means of achieving that outcome.


[Foliot]
> >> With that clarified, *one* technique, a valid, useful and well
> supported
> >> technique, for providing a long description to any <img>, regardless
> >> whether
> >> it is PNG, GIF, JPG or SVG, is to use the @longdesc attribute. I am
> >> strongly
> >> opposed to any language in the specification that might suggest that
> >> @longdesc is somehow "flawed":
> >>

(For new-comers, the following quote is the heart of the problem for me)

> >>> James Craig wrote:
> >>>>>>>> 3. @longdesc is inappropriate for SVG graphics. Make
> >>>>>>>> the SVG DOM accessible instead.
> >>
> >> What exactly is inappropriate with the following?
> >>
> >>  <img id="img" alt="smiley face" src="smiley.svg"
> >> longdesc="smileyface.html" />
> >
[Craig]
> > It's inappropriate because the short and long description can and
> should
> > be stored in the SVG DOM.
> 
[Schepers]
> I tend to agree with this sentiment, and would hate to see SVG
> accessibility best practices and implementation support be discouraged
> or not get the attention they deserve, all in the interest of promoting
> @longdesc.

As I have previously noted, this thread started based upon feedback to the HTML5 Image Description Extension, and SVG got "roped in". *IF* a content author cannot modify the SVG (for whatever reason), then the ability to use <img> + SVG image + the longdesc attribute should be, and is, a viable alternative. I cannot see why the spec that is the HTML5 Image Description Extension start suggesting that authors not use the sole attribute that _is_ the entire extension specification.  The suitability or "appropriateness" of using that combination is an author decision that rightly belongs in authoring guidelines, not specifications. If you/James/somebody wants to propose that for a WCAG Techniques I'd support that, but not in the spec itself. (Key WCAG contacts are Andrew Kirkpatrick, and James Nurthen & Josh O'Connor who have been collecting and collating "new" HTML5 techniques.)

Besides, as you yourself noted just today (http://schepers.cc/authoring-accessible-svg), from the limited testing you did, neither screen reader you used read <title>, (and I will presume <desc> content) in "...standalone SVG files, nor read SVG files referenced in <iframe>, <object>, <embed>, or <img> elements of an HTML page", so while the "code purity" of James' statement sounds right, the practical outcomes today are less than universally useful.


[Schepers] 
> It's not that I'm prejudiced towards SVG (though I am), but rather that
> I see image-stored descriptions as an inherently superior technique.

I don't disagree at all. We just don't have the support today that we need. 

Moving towards images that always have short and long descriptions included "in the wrapper" is a great goal, and one I could work hard to support. But that requires a complete overhaul of not only the tool-chains used to create those images, but also the browsers and assistive technology used by PWD to leverage that significant change. And even if/when we get all that fixed and "up-to-speed", there is a long-tail effect at play that suggests that it would take anywhere from 1 year to 5 or more years to see widespread pickup of supporting technologies by end users.

Meanwhile, we have a need now, and a solution now that works, albeit not universally, but still, it works, and with some additional lift on the part of the browser vendors it would work even better. (However, as you noted in your blog, some strongly held opinions against @longdesc are out there, still today.)

[Schepers]
> Give an author a @longdesc, and it works in one website; give an author
> a image with its image-stored description, and it works on every
> website. It doesn't get decontextualized when the image is changed; it
> goes with the image when it's saved or reused.
> 
> But beyond that, I'd be concerned that telling people to use @longdesc
> would distract from making SVG images (and SVG applications or
> interactive images) accessible.

I don't think anyone is saying *only* use @longdesc, certainly I'm not advocating for it. 

However, I am also against actively advocating for *not* using @longdesc, if and when it's use solves an immediate problem, and I certainly don't think the place for that kind of author guidance is in the specification itself. 

My colleague however has a perspective and well known history that does favor actively dismissing @longdesc, and has gone to great lengths in the past to try and show how other techniques can also be used (and so therefore we should stop trying to support @longdesc). I am in favor of multiple techniques, but I stop at dismissing one over the other when the one being dismissed has active and fairly robust support today, unlike some of the other suggested techniques that are being surfaced. I again point to the fact that even your testing shows that <title> and <desc> are not being used when an SVG image is referenced with any number of HTML elements (<object>, <img>, etc.). Why should we dismiss one solution while at the same time promote another with just as many if not more non-support problems?

[Schepers]
> This also goes for implementers; I
> don't
> want an implementer to beg off doing SVG accessibility because they
> support @longdesc, which is simply not as good for complex cases as an
> accessible SVG.

Doug, I think that any implementer who used that argument should be ashamed of that argument, and I would have no hesitation publicly and loudly calling them out on that (you know me). Unless however someone can actually show an instance of "harm" from using the <img> + SVG + @longdesc pattern, I say we leave it as a viable solution, and let authors decide what is the best solution for their context. Comments in the specification of the appropriateness or inappropriateness of any usage is, well, inappropriate.  


> 
> I'd also be mildly concerned that, from the user perspective, an SVG
> image with @longdesc would deflect from any image-stored description,
> but that's fairly minor.
> 
>
[Foliot] 
> >> (real world example - see:
> >> http://www.schepers.cc/svg/blendups/embedding.html - minus the
> longdesc
> >> attribute however)
> 
[Schepers]
> As James pointed out, my SVG image there did have a text alternative,
> and I feel it was an appropriate one. Personally, I'm going to focus my
> attention on getting better support for SVG in screenreaders, because I
> feel there's a bigger bang for the buck.

Yup, and I pointed to that page mostly to show that using <img> + SVG not only is a viable authoring choice, but that that pattern had some pretty decent user-agent support. Again, while this might feel like a SVG discussion to you, it is (for me) a @longdesc discussion, and what the final extension specification does or does not say about how and when to use @longdesc.


[Foliot]
> >> I agree that making the DOM accessible is a good thing, but I
> disagree
> >>
> >> that using @longdesc as described in the example above is
> "inappropriate"
> >>  - that is a false and misleading statement, and the source of
> >> my consternation.
> >
[Craig]
> > I disagree that it's misleading.
> >
> > In a similar vein, it's inappropriate to use tables for layout, and
> > authors should use CSS for layout when appropriate. That's not the
> same
> > as saying tables for layout are inherently harmful (layout tables can
> be
> > made reasonably accessible), there are just better techniques
> available
> > now, and authors should use those better techniques when they can.
> >
[Foliot]
> >> I will oppose any suggestion then that using something like:
> >>
> >> <img src="complex_piechart.svg" alt="Piechart: user statistics"
> >> longdesc="userstatistics.html">
> >>
> >> ...is inappropriate. It isn't, it is wholly appropriate in context,
> >
[Craig]
> > I disagree.
> >
[Foliot]
> >> has great support in most screen readers,
> >
[Craig]
> > You're being subjective again. Don't you mean "works in two screen
> > readers?" Even if the number was higher, like five, that's still not
> > "most" screen readers, and if I'm not mistaken, it's not even
> available
> > in "most" browsers.

(In an earlier response to James I addressed this comment thusly:)

Actually, I mean “most”, as in:
• Adaptive Multimedia Information System (AMIS)
• AnyDaisy FF Extension
• gh Player
• JAWS (Version 4.01 and up)
• LookOUT in combination with WebbIE
• NVDA
• Sense Reader Professional Edition v1.1.0.6 (Korean)
• SuperNova/Hal
• Thunder in combination with WebbIE
• Window-Eyes
• (Home Page Reader has native support of longdesc and is still used in Japan for longdesc.)
(source: http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation)  

As well, according to the (imperfect) survey information from WebAIM (http://webaim.org/projects/screenreadersurvey4/#primary) close to 90% of screen reader users surveyed are using at least one screen reader that supports @longdesc.  So no, I don’t just mean “it works in 2 screen readers”, I mean that it is a viable and workable solution for anyone not using MacOS / iOS.

As for browser support*, with support in IE+JAWs, Firefox+NVDA, and emergent support in Blink based browsers (Chrome+Chromevox) I also stand behind my claim of “most browsers” as well.

(* support being a subjective term. Exposure of the attribute in the DOM and to the Accessibility APIs is there, and using combinations of browsers and assistive technology tools (or sometimes just browser extensions or plugins) means that any user on any platform besides Mac OS/iOS can “get to” longdesc content with the right tool-set. This is not Mac/Apple bashing, this is statement of facts.)

[Foliot]
> >> and it would be truly awesome if it
> >> saw support in WebKit + VoiceOver as well, continuing Apple's
> tradition of
> >> striving for full HTML5 standards support.
> >
[Craig]
> > If you code your SVG accessibly, it can work, regardless of the
> longdesc
> > workaround.
>
[Schepers]
> I'm not concerned about @longdesc one way or another, so I don't have a
> horse in this particular race. I will say that I generally agree with
> the notion that different techniques are appropriate for different use
> cases, and that I don't think it would detract from the spec to mention
> additional techniques, or cases where @longdesc is better or more
> poorly suited.

Well, I *am* concerned about @longdesc. With regard to your 'notion' I can meet you most of the way there: I agree that authors can and should be told of all possible options to make any page element as accessible as possible (based on use-cases and context); I agree that multiple choices is and always has been a good strategy to offer authors (as it aids in flexibility - too often accessibility is seen as very rigid, and I hate that), but I fall short of the use of "negative" language (specifically the term "inappropriate"), and I believe that author guidance (which can and does change over time) should be considered non-normative and not included in a specification, especially since when it comes to accessibility, we have the WCAG success criteria, which represents the "living" part of the larger picture. *THAT* is where authoring guidance on how to create accessible foobars exists, and WAI has a long history and effort invested in pointing authors to that resource as the best place to get their guidance.

JF

Received on Thursday, 5 September 2013 05:48:06 UTC