Re: @alt descriptions for Thing Descriptions

Hi Evan,

On 19/06/2019 20:44, Yamanishi, Evan wrote:

> One of the secondary effects of exposing long descriptions to everyone (from the perspective of a publisher) is that it ends up being better reviewed and edited. This is one of my goals for the extended image description library that Charles mentioned. Our editorial staff has a deeply-held need to correct bad copy and poor pedagogy but when long descriptions are hard to review in context, it's difficult to give it the same care as other copy.
That's an interesting perspective that I hadn't considered.
> In the long run, my hope is that a universally designed image experience will encourage non-accessibility staff to make better decisions about what constitutes meaningful material, whether it's extensive prose, an interactive SVG, or something entirely different.

Just to add to that, is I think a part of the challenge is that the 
author or publisher etc usually doesn't understand how these alternate 
content descriptions are going to be consumed by AT/the user.

It is one thing to say, describe this content using @alt, then 
demonstrate how the user may navigate to it and hear this content, but 
it is a leap when you show how more complex content like a data table 
can be queried and navigated. I think there is a parallel between using 
terse descriptors that are quickly and easily consumed by AT and having 
a more complex structure - a la SVG or whatever, and understanding how 
the AT user can navigate and query the content as objects (as such) as 
well as understanding the relationships between nodes and so on.

> To do that, we'll need good guidance about best practices for setting that content, including when it might make sense to have descriptive text and when it makes sense to use something less linear and more interactive.

+1.

Thanks

Josh


> I suspect the advice shouldn't be, "never use long descriptions."
>
> Evan
>
>
> Evan Yamanishi
> Accessibility Lead | Director of the Norton Lab
>   
> W. W. Norton & Company <https://www.wwnorton.com/>
> Independent & Employee-Owned
> 500 5th Avenue, New York, NY 10110
>
>
> On 6/19/19, 5:56 AM, "Joshue O Connor" <joconnor@w3.org> wrote:
>
>      
>      EXTERNAL EMAIL
>      
>      
>      On 18/06/2019 23:09, Volker Sorge wrote:
>      
>      > [Being late to the thread, I am trying to piece together what I can.
>      > So forgive me if I pick up on the wrong points!]
>      >
>      > I am not a fan of long descriptions. [...]Thus enabling interaction with
>      > diagrams is important.
>      > Luckily SVG gives us most (but not everything) we need for this.
>      > That's how I could fold multiple layers of description into chemistry
>      > diagrams and expose it for interactive exploration.  And we are
>      > currently porting this to physics and data visualisations.
>      >
>      > And I fully agree with John that all this should not be restricted to
>      > AT users only. In particular in the teaching and learning space it can
>      > be useful for anyone.
>      
>      That's interesting, so ideas on how to do that are welcome. A roadmap
>      for the creation of accessible diagrams and charts for technical specs
>      looks like it is needed. It will be useful for other specs.
>      
>      We need to walk the line between creating lower level linear type
>      descriptions, and more interactive charts that the user can interrogate
>      and understand the relationship between nodes/items contained.
>      
>      Thanks
>      
>      Josh
>      
>      >
>      > Best,
>      > Volker
>      >
>      > On Thu, 13 Jun 2019 at 19:43, Charles LaPierre <charlesl@benetech.org> wrote:
>      >> So as George Stated, we have created some Test EPUB books which has below an image (which has simple alt text) an aria-details linked HTML Summary/Details which has the extended image description which as John points out was one of the main reason why longdesc hasn’t made any traction that this information should be accessible to everyone not just assistive technologies.  W.W. Norton and others at the Web4All/DIAGRAM Hackathon expanded this notion and made a very nice UI that publishers could potentially use.  We are testing these out with various reading systems and will be looking to make this work from the hackathon which includes documentation into a potential library.
>      >>
>      >> As for Accessible SVG, I know there are some issues on exposing the sub-components of an SVG to Assistive technology, Volker Sorge has done some work in this field to make a Chemical equation in SVG completely navigable using JavaScript.  So its possible but I am sure it could be improved and make easier.
>      >>
>      >>
>      >> Thanks
>      >> EOM
>      >> Charles LaPierre
>      >> Technical Lead, DIAGRAM and Born Accessible
>      >> Twitter: @CLaPierreA11Y
>      >> Skype: charles_lapierre
>      >>
>      >>
>      >> On Jun 13, 2019, at 11:33 AM, Janina Sajka <janina@rednote.net> wrote:
>      >>
>      >> So, our prime complaint and remediation is explanatory Summary/Details.
>      >> That's the required WCAG conformance on this W3C document, and I think
>      >> it matters a lot in this instance in particular.
>      >>
>      >> Secondary is the use of accessible SVG. It's secondary because it's an
>      >> emerging technology. Yes, we should eat our own dog food, but perhaps
>      >> the dog food is missing some essential nutrients? Therefore, it's
>      >> secondary and we don't fall on our swords over SVG.
>      >>
>      >> Sound right?
>      >>
>      >> John Foliot writes:
>      >>
>      >> My vote would be for both, given that the major argument we got from "back
>      >> in the day" (ref: the attribute I am not allow to speak of out loud) is
>      >> that these extended descriptions should be available to all users, and not
>      >> just screen reader users...
>      >>
>      >> (Additionally, and I've not kept track, is how accessible are accessible
>      >> SVGs? It seems, as Joshue noted, that there is both a complex visual
>      >> representation, but the bigger challenge is also explaining the
>      >> relationships in that representation).
>      >>
>      >> JF
>      >>
>      >> On Thu, Jun 13, 2019 at 12:39 PM Janina Sajka <janina@rednote.net> wrote:
>      >>
>      >> I wonder whether it would be most prudent to push for both accessible
>      >> SVG and Summary/Details explanatory text?
>      >>
>      >> George Kerscher writes:
>      >>
>      >> Hi,
>      >>
>      >> I think that there may be at least two good alternatives for complex
>      >> graphics. SVG, as you suggest and I am looking forward to guidance on
>      >>
>      >> these.
>      >>
>      >>
>      >> In addition there is the extended description approach, where a textual
>      >> description may be more appropriate. We have collected some approaches in
>      >> the extended description EPUB you can download from:
>      >> http://www.epubtest.org/testbooks
>      >> This takes advantage of the details element with its expanding and
>      >> collapsing   nature. This may be less intrusive to the reader, and yet
>      >>
>      >> it is
>      >>
>      >> available to anybody who wants more information.
>      >>
>      >> Best
>      >> George
>      >>
>      >>
>      >> -----Original Message-----
>      >> From: Janina Sajka (janina@rednote.net) <janina@rednote.net>
>      >> Sent: Thursday, June 13, 2019 8:18 AM
>      >> To: Joshue O Connor <joconnor@w3.org>
>      >> Cc: W3C WAI Accessible Platform Architectures <public-apa@w3.org>
>      >> Subject: Re: @alt descriptions for Thing Descriptions
>      >>
>      >> Long descriptions? Nah, we killed those with HTML 5, right? Who needs
>      >> those! <grin>
>      >>
>      >> On a serious note, should we be recommending these be SVG so that we can
>      >> use accessible SVG and someone can actually explore the relationship
>      >> matrix directly?
>      >>
>      >> Joshue O Connor writes:
>      >>
>      >> On 13/06/2019 15:03, Janina Sajka (janina@rednote.net) wrote:
>      >>
>      >> Hey, Josh:
>      >>
>      >> +APA list
>      >>
>      >> So, you're more the expert on WCAG requirements for such "things,
>      >>
>      >> ..."
>      >>
>      >> ----- Sorry, couldn't resist!
>      >>
>      >>
>      >> Boom Boom!
>      >>
>      >>
>      >> Question: Are these detailed in the text otherwise provided by the
>      >>
>      >> spec?
>      >>
>      >>
>      >> Not really, or at least the visual representation shows how objects,
>      >>
>      >> classes
>      >>
>      >> and instances of same relate to each other.
>      >>
>      >> There are lots of nodes and arrows showing relationships. I'll have a
>      >>
>      >> go
>      >>
>      >> at
>      >>
>      >> abstracting them out and will forward to the list.
>      >>
>      >>
>      >> If so, simply giving good alt should be sufficient,
>      >>
>      >>
>      >> These are for sure in the @longdesc section *grin.
>      >>
>      >> Thanks
>      >>
>      >> Josh
>      >>
>      >>
>      >> right? Else, yes
>      >> please!
>      >>
>      >> Best,
>      >>
>      >> Janina
>      >>
>      >> Joshue O Connor writes:
>      >>
>      >> Hi Janina,
>      >>
>      >> I'm reviewing the Thing Description in more detail and have looked
>      >>
>      >> at
>      >>
>      >> the
>      >>
>      >> figures contained in it. There are ~5.
>      >>
>      >> The @alt for 4 of them is 'UML diagram of the TD information model
>      >>
>      >> for
>      >>
>      >> the
>      >>
>      >> hypermedia controls vocabulary' and they represent:
>      >>
>      >> Figure1TD core vocabulary,
>      >> Figure2JSON schema vocabulary
>      >> Figure3WoT security vocabulary
>      >> Figure4Hypermedia controls vocabulary
>      >>
>      >> Do you want me to write up in detail the UML descriptions?
>      >>
>      >> They take the form:
>      >>
>      >> <example>
>      >>
>      >> Thing (linking to Form/Link/Multilanguage/VersionInfo)
>      >>
>      >> @context :anyURL (or Array)
>      >>
>      >> @type: string
>      >>
>      >> id: anyURI
>      >>
>      >> [...]
>      >>
>      >> </example>
>      >>
>      >> They are a little gnarly to describe but I can do it if you need
>      >>
>      >> it.
>      >>
>      >>
>      >> Whereas one of them represents a representation of a 'TD
>      >>
>      >> Serialization, TD
>      >>
>      >> and Thing on a light switch example' which is again a JSON type
>      >> visualisation.
>      >>
>      >> Ok, it will take a little time, but that's ok if its helpful to
>      >>
>      >> you.
>      >>
>      >>
>      >> Josh
>      >>
>      >> --
>      >> Emerging Web Technology Specialist/A11y (WAI/W3C)
>      >>
>      >> --
>      >> Emerging Web Technology Specialist/A11y (WAI/W3C)
>      >>
>      >>
>      >> --
>      >>
>      >> Janina Sajka
>      >>
>      >> Linux Foundation Fellow
>      >> Executive Chair, Accessibility Workgroup:     http://a11y.org
>      >>
>      >> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>      >> Chair, Accessible Platform Architectures      http://www.w3.org/wai/apa
>      >>
>      >>
>      >>
>      >>
>      >> --
>      >>
>      >> Janina Sajka
>      >>
>      >> Linux Foundation Fellow
>      >> Executive Chair, Accessibility Workgroup:       http://a11y.org
>      >>
>      >> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>      >> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
>      >>
>      >>
>      >>
>      >>
>      >> --
>      >> *John Foliot* | Principal Accessibility Strategist | W3C AC Representative
>      >> Deque Systems - Accessibility for Good
>      >> deque.com
>      >>
>      >>
>      >> --
>      >>
>      >> Janina Sajka
>      >>
>      >> Linux Foundation Fellow
>      >> Executive Chair, Accessibility Workgroup: http://a11y.org
>      >>
>      >> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>      >> Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
>      >>
>      >>
>      >>
>      --
>      Emerging Web Technology Specialist/A11y (WAI/W3C)
>      
>      
>
-- 
Emerging Web Technology Specialist/A11y (WAI/W3C)

Received on Thursday, 20 June 2019 08:48:48 UTC