DIAGRAM Tools Working Group Notes 5-23-13

Skip to end of metadata
Go to start of metadata

DIAGRAM Tools Working Group 5/23/13


George Kerscher

Geoff Freed

Gerardo Capiel

Neil Soiffer

Ron Stewart

John Gardner


Josh Miele

Ed Summers

Richard Ladner

Ge Vue

Anh Bui


George:  update on longdesc in EPUB3 revision

-- Apple is opposed to @longdesc; proposes hiding long descriptions in hidden iframes instead.

-- aria-describedAt is the current favorite, but this won't be finished until 2014 when it is included in ARIA 1.1

-- EPUB is hoping to resolve this issue by the end of June

Ron: why is Apple opposed?

George:  @longdesc is now being included in HTML5 as an extension spec; it is limited to a temporary solution and so Apple probably wants a permanent solution.

Gerardo:  favors @longdesc because it is supported by all major screen readers except VoiceOver

Neil:  but it is limited only to images

Gerardo: @longdesc not implemented in Poet yet, since it’s not used in DAISY; currently long descriptions go into <prodnote>.  Planning to implement EPUBB3 support later this year will have to have a resolution to the EPUB long-description issue by then.

DAISY Pipeline currently puts descriptions into aside note.

Ron:  having problems generating long descriptions from DP that will play with DTB players.  Problem appears to be limited to Mac, not Windows.  (Players are the problem, not the generator of the DTB.)

George:  why do we worry about assistive technology regarding long descriptions?  Wouldn't it be on the reading system?  Wouldn't it be more like a footnote reference?

Gerardo:  but doesn't there have to be a mechanism for the AT to know that the description is there?

George:  @longdesc is supported by the reading system/AT, not the browser.  Wouldn't the next-gen reading systems need to include the presentation to any reader that there is extended info about any particular element?  Isn't that what's done in Readium?

Ron:  what about other AT (not screen readers)?  If it's exposed to the system, it's up to the reading system to make it available.

Gerardo:  true.

Ron: that's back to having a lot of variability of delivery methods; it's up to the reading system to deliver the information.,

George:  if we hang describedAt on <canvas>, then the reading system should present the info that *something* is available to all users.

Ron:  correct-- it's a usability thing.

George:  support for @longdesc in screen readers is attractive now, but may not be the sole reason for future support.  If we wind up with describedAt, it will fall upon the accessibility industry to implement it in Readium and Readium SDK.

Gerardo:  agree.

Ron: @longdesc is an interim solution

George:  @longdesc probably won't fly in EPUB, though.  Publishers are now asking to be *told* what they need to do now, and in the long term.

Ron: agree.

George:  Should we try to meet with Markus, Matt and others?  Rich S/IBM thinks we should push hard for aria-describedAt; ARIA group will be meeting June 3 and Markus will be on that call w/George; maybe this WG could be on the call as well?

Ron:  the issue must be resolved somehow.

George:  the editor's draft (of EPUB?) as soon as the ARIA group says one is available.  If we (Tools WG) see problems, we can provide feedback before it is turned into a FPWD.  There were objections over the request that describedAt accept multiple URIs, but would settle to limit it to a single URI instead.

Ron:  go to a single URI and then branch from there?

George: Yes; whether that URI links to other resources, or is a query to a database, etc., yes.

Gerardo:  agree with these arguments.

Geoff:  what about supporting both @longdesc and describedAt?  won't systems need to do both?

Ron:  true; descriptions will need to be available to legacy systems as well as new ones.

John:  is the SVG2 working group still extant?

Neil:  don't know.

George:  wasn't SVG2 recently moved into recommendation?

John:  haven't heard anything lately.

Neil: still chartered into next year.

Ron:  they released a working draft on April 9:  [http://www.w3.org/TR/SVG2/

Gerardo:  (reads Math info from working draft).  Guessing that they're embedding MathML within SVG?

John:  yes.

Gerardo:  there are issues w/providing info in the <text> element (which is the current recommendation) and also doing an aria-label to gain broader support, which is that screen readers may actually read both labels.

John:  have spent time looking into this; no browser/screen-reader combination provides the best solution; some give way too much information and some give not enough.

Is a chicken/egg problem; browser must expose info before screen readers can do anything.

Gerardo:  move on to next item-- accessible OER sprint w/wide range of organizations in OER arena.  Idea was to bring accessibility community and OER community together.  Discussed many things:  display/conveyance of math in browsers.  Explored server-side generation of MathML into SVG w/automatically generated descriptions using aria-label.  Had a hacked-up working prototype; could be extended into DAISY Pipeline or other Web applications.  Could provide a stopgap for dealing with the lack of MathML support. 

Also did things with OERPUB editor with adding accessibility options, such as structural navigation.  Had a paper prototype for crowdsourcing correction of automatically generated math descriptions.  Also had someone there from Hypothesis; worked with them to help make their Web/e-book annotation tool more accessible.

George:  between W3C and IDPF there may be a solution for accessible annotations in EPUB3.1.

Gerardo:  Hypothesis is building an open-source annotation system.

Ron:  was there any work done on existing systems and how they render content such as SVG and MathML?

Gerardo:  Connexions is working on EPUB3 output which will have MathML in it:  having MathML rendered in SVG and also be part of the SVG metadata.  Probably 6-12 months for this major updgrade.

John:  when you do MathML into SVG, where does the MathML go?  Into <desc>?

Gerardo:  not sure-- it's a prototype.

John:  would like it to go into a math field that is associated with an object or region.  Made a fairly detailed recommendation based on structured text; can't remember exactly.

Gerardo:  in the process of exploring this; had thought that it would go into <desc> but am open to others.

John:  should be a standard place to put the MathML; a new element might be a better idea rather than reusing an existing element such as <desc>.

George:  are ARIA attributes available inside an SVG?

John:  yes, but they are not well supported or even well defined.

George:  this may be another potential use case for describedAt.

John:  <desc> could be used the same way as describedAt.

George:  can you put MathML in <desc> now?

Ron:  also depends on how it's rendered. 

John:  presentational MathML is okay; structure can be a problem.  Commonly available reading systems won't render complex properly.

Gerardo:  out of time; expect a summary of the OER event on the DIAGRAM list soon.


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.