Minutes: August 13, 2015 ARIA Task Force Meeting (meeting with publishers)

http://www.w3.org/2015/08/13-aria-minutes.html


Text:


- DRAFT -
Protocols and Formats Working Group Teleconference
13 Aug 2015


See also: IRC log


Attendees
Present
      janina, Rich_Schwerdtfeger, David_Singer, Markus_Gylling,
      Avneesh-Singh, Tzviya, Joanmarie_Diggs, Ted, LJWatson, clapierre,
      Keith_Creasy, Avneesh_Singh, Ivan, George_Kerscher, Matt_Garrish,
      fesch, Tom_Starbranch, Larry_Skutchan, Deborah_Kaplan, Daniel_Weck,
      MichaelC, James_Craig
Regrets
Chair
      Rich
Scribe
      mgylling
Contents
      Topics
         1. requirements from the publishing industry
         2. aria.describedAt
      Summary of Action Items



<trackbot> Date: 13 August 2015


<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus


<richardschwerdtfeger> Agenda:


<richardschwerdtfeger>
https://lists.w3.org/Archives/Public/public-pfwg/2015Aug/0038.html



<richardschwerdtfeger> Publisher Requirements:


<richardschwerdtfeger>
https://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_extended_descriptions



<scribe> scribenick: mgylling


Rich: when people speak, please say your name


… first quickly go around the table, say who you are and what comapny you
are from


[staff and chairs introduce themselves]


Leonie: from the Paciello group


Tzviya: DPUB IG chair, Wiley


George: with DAISY and IDPF


<dsinger> Apple is usually James Craig, but today we have Ted O’Connor
(hober) here supported by Dave Singer (dsinger)


Ric Wright with Readium


<jcraig> I'm here Rich


Keith Creasy with APH, interested particularly in Braille


<jcraig> I've here Dave


Deborah Kaplan, chair if DPUB A11/ TF, Safari Books Online


Avneesh Singh, DAISY


Charles LaPierre, Benetech, co-chair DPUB A11Y TF


Mallorie Bontrager


Mia Lipner, Pearson, Accessibility Manager


Tob Starbranch, Pearson, Director of learning services


Jason White, ETS


Ivan Herman, W3C, DPUB IG staff contact


Jon Gunderson, University of Illinois


Dave Cramer, Hachette


Daniel Weck, DAISY Consortium and Readium


Joanie Diggs, Igalia, ARIA spec co-editor, developer of the Orca screen
reader


Joan??3, University of Illinois Library


Julie Morris, BISG


Larry Skutchan, APH


Ed McCoyd, AAP


Ted O’Connor, Webkit team at Apple


David Singer, Apple


<richardschwerdtfeger>
https://lists.w3.org/Archives/Public/public-pfwg/2015Aug/0038.html



<jcraig> James Craig, Apple


<richardschwerdtfeger>
https://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_extended_descriptions



requirements from the publishing industry


Tzviya: implicit to this, there has to be support from all UAs, publishing
like all other industries has problem with old browsers


… We are talking about images as well as non-images. We need to provide
rich descriptions for several things.


… these need to support rich markup


… we want to use same method for all types of objects


… these should be reusable between multiple documents


… unambiguous nature of the source and description exposed to AT and UAs


… these descriptions should be complex or bloat the page in any way


… not necessarily visible in html, discoverable and skippable


<Zakim> LJWatson, you wanted to ask what is meant by "not visible in the
HTML"?


LjWatson: whats meant by not visible in the HTML?


Deborah: basically, we dont want it to necessarily change the design, e.g.
art book or picture book by adding this extra information. We do however
want AT to get to it, and optionally generic UA users as well via settings


<dsinger> ah, “must not force a change in the visible appearance of the
content"?


<Zakim> jcraig, you wanted to ask how this could be possible if "no browser
updates" are a requirement?


jcraig: I dont see how "new feature requirements" are possible if we on of
the other requirements is "we can't require updates of legacy browsers"


tzviya: we didnt say it needs to be backwards compatible, just that we need
support moving forward


mia: thats my take on it as well


rich: to james’s point, its going to be hard to retrofit in older browsers,
no changes to IE only in Edge. Is that a viable route for the publishing
industry. Second your saying AT access, but also allow book readers or
browsers to render the content?


… is using a browser that supports details viable?


dkaplan: first point: we understand that the past is the past and that
there is only so much retrofitting we can do. We do need there to be buy-in
in raeding systems and user agents that this will be supported


… we would rather have the right thing supported in Edge moving forward,
than have nothing


… second question: what we really need is both in terms of viewable and not
viewable. Details could possibly work if some of our questions are
addressable. We do want to be able by users or content creators choice to
expose this to non-AT UAs


… but there are cases in publishing where either businesswise or legally
exposing these things is a non-starter.


… Samuel Becket was very picky [??4]


… it has to be something that can be hidden by default


rich: good point, I hadn’t heard that requirement yet


tzviya: its not just legal, book designers have this requirement as well


<Zakim> jcraig, you wanted to answer any questions you have about details
(doesn't require visual changes) and SVG (can be used for raster/bitmaps)


<jcraig> http://cookiecrook.com/longdesc/



<jcraig> http://cookiecrook.com/longdesc/svg_bitmap/



jcraig: I wanted to offer to respond re the details element. It does not
require visual presence on the screen. The other misconception on the wiki
is that people seem to be under the impression that SVG cant represent
raster or bitmap images


… neither requires a visual change to the layout


George: details wraps an element which may need a description, if details
is hidden is the element that it wraps also hidden?


jcraig: depends on whether you mean visually hidden


… some activiation could result in rendering the content either visually or
to AT


rich: you also want to have the browser ask to turn these things on?


dkaplan: the particular concern, the specific requirement is that we want
to be able to say, here is a visual thing, here is consistent semantic link
to a description, that AT knows, that can be hidden or shown on demand


… no matter what SVG is capable of, we cant tell publishing to start using
SVG


Ted: the images can still be raster and referenced from SVG


<Zakim> joanie, you wanted to ask about longdesc, in particular: Is the
only problem that it is (currently) only usable for images? If longdesc
were expanded to be applicable to any


joanie: longdesc on the wiki, is that the only problem longdesc has?


… if it were expanded, if it could be applied to any element, are there any
other blockers


browser objections, lack of support


<Zakim> tzviya, you wanted to ask about functional a11y of SVG


tzviya: question on the feasibility of SVG, I know ARIA has been working on
that, where is that work?


jcraig: my bitmap example, on mac it runs on chrome safari firefox [??5]


<Zakim> janina, you wanted to clarify whether content rendering includes
the user agent chrome


janina: might be useful to note, I think there is a distinction when we
talk about rendering, that we always have some level of chrome in the UA,
that some controls are visible somewhere, I assume we dont mean the chrome
when we say affecting content?


dkaplan: right, it is acceptable to say you turned on an option [??7]


LJWatson: if we have details and summary and hide the summary off-screen,
how then do we make that visible to people with cognitive disabilities?
this is...


jason: Mark Hakkinen (ETS) is working on the use of Web Components to
present rich alternatives, including long descriptions and printing


… wrapped in a web component that surrounds an image, and can use CSS, can
rely on personal needs a preferences profile


… we have a commitment by a number of UA developers, also there are
polyfills available now. Thats what we’ve been working on here. Think its a
powerful solution that draws on general mechanisms used on the general web


<Zakim> jcraig, you wanted to mention this sounds like the @media
(prefers-extended-descriptions) CSS media feature


<MichielBijl> Explanation of chrome versus content, chrome shown in red
boxes, content in green boxes:
http://agosto.nl/dir/accessibility/content-chrome.png



<LJWatson> ...the crux of what we need to solve, is whats rendered and
where that choice gets made/


jcraig: adding stuff to the browser chrome is not a likely path forward, we
should concentrate on rendering engines, one related thing is media
features


… prefers differentiation without color setting


… we could do something similar here to turn default rendering on or off.
This would be further work in CSSWG


rich: you have to be able to set it somewhere in the OS but not necessarily
in the browser itself


jcraig: right. user CSS, browser GUI, or OS GUI.


judy: glad to hear multiple options being discussed, we should try to make
sure that the questions opened are tracked down after the meeting


… look further into this offline, and pull together a view of what works
and what doesnt, which things are easily fixable


<tzviya> +1 to follow up discussion


<joanie> I would request/suggest the details Judy is talking about also
wind up in the wiki page we're discussing


rich: we are trying to get the issues out and will then focus on action
items


Tom: delivering descriptions that are narrative in nature [??8]


george: we’ve got the diagram center work with a content model, short
summary, long description, simplified languauge, alternative, tactile
views, 3d printer version, all kinds of enhancements that could be linked
to


we’re thinking that it could be showed in the browser via XSLT


Ted: why would we want to expose arbitrary XML to the browser?


Tom_Starbranch+: One example is ChartML


keith: we are talking about descriptions as narrative, but for a braille
reader there are other options that are sometimes preferable. Most browsers
support unicode braille now. Using braille symbols that act as pointers. In
a textbook some is graphical, some is text. Much more easily understood as
braille than as a narrative description.


… we need to not exclude formatted braille, tactile graphics that are not
narrative descriptions. The diagram content model does allow for multiple
alternatives


<Zakim> LJWatson, you wanted to ask if we can introduce an application/OS
pref for "show extended descriptions", why then not extend longdesc to all
elements - since the lack of GUI


Leonie: on joanies question, if there is a possibility within as OS or app
to toggle visibility, doesnt that makes want to look on extending longdesc
to other elements?


<Zakim> jcraig, you wanted to ask if you could deliver it via <a href> and
to say or http content negotiation and to say including .brf braille files


jcraig: we’ve posted our objections to longdesc, thats gonna be a
non-starter for us


dkaplan: DPUB is element agnostic as long as our requirements are met. We
agree with Leonie in that there is an affordance problem in finding or
discovering settings


léonie: is that an irreconcilable problem then?


dkaplan: there are approaches in UI design, if it is an option that is
built into the OS or reading system, the publication can say “by the way if
you need these…” an easy to change thing that a non technical user can
handle


Tom: if it is extremely hard to make content accessible […?]


<jcraig> you wanted to ask if you could deliver it via <a href> and to say
or http content negotiation and to say including .brf braille files


jcraig: first of all, 3d models, brf files, sounds like we are growing the
requirements in ways I dont know if they are achievable. We should focus on
minimal requirements. There are ways to serve that content…


keith: I was talking about unicode braille, not BRF


<LJWatson> +1 to focusing requirements


jcraig: can be served in standard ways today, a href or http content
negotiation


… think this is separate from todays discussion


Tom: Are you including ChartML in this?


jcraig: yes, can be linked or content negotiated the same way


Tom: my concern is that everybody would create their own solution


rich: george mentioned earlier that you want to be able to reuse the
alternative content. When we look at details, is it unrealistic to ask for
a src attribute, and plugins for custom formats?


… and there are security concerns


Tom: we’re not convinced that the browser is the right way to render this,
we want a low barrier for entry


<jasonjgw> date


dkaplan: there’s two separate issues there: as far as resuability goes, use
case is say you have a bunch text books that can reuse an update one single
instance of the description. The separate thing of rendering things that
are not native to the browser, it is reasonable to say we would like to be
able to render marked up text natively in the browser, and things on top of
that via plugins, and I think that is fine


<jcraig> +1 to dkaplan3's bringing the conversation back to reasonable
scoping


<jasonjgw> Writing my comment in IRC: a media query or similar mechanism
would enable our web components to choose from among the alternatives
without introducing a user interface into the rendering of the content.
This is a missing capability that would significantly support the Web
Component approach.


rich: currently if you have a src attribute, you just get on piece of
content. Do you want arbitration by the browser? Aria-describedAt does not
allow for this


<jcraig> Time check... Call is wrapping up.


george: we were looking with the diagrammar to use XSLT to create a single
html page, and the user would select which item they want


… we’d love to see personalization in the future


… but I dont know that we can get there today


mia: I’d like to echo that, realizing that coming up with multiple
alternatves makes things complicated and may not be feasible in the short
term, but we should keep an eye on it for the future


Tom: Using ChartML, we want to deliver this as graphs, how do we get that
to user agent with a low barries of entry


… that can use with any app or plugin that they choose


<Zakim> tzviya, you wanted to say that it is solvable - there are many
things build into UI that users control and users (even my dad) have
figured out and to suggest that a small group of


jason: I put most of my comments into IRC. The diagrammar is what Mark
Hakkinens work with Web Components is based on


aria.describedAt


<richardschwerdtfeger>
https://lists.w3.org/Archives/Public/public-pfwg/2015Jul/0102.html



rich: we’ve seen the Apple objection to longdesc, is one of the issues that
you want to maintain context?


… that the external URL is launched in a separate tab, which gives a change
in context. Or is there other issues like that?


jcraig: there is a variety of ways that you can maintain context even with
a standard link


rich; if accessing the external meant creating a new tab, was that your
concern?


jcraig: our objection within the book publishing context, say iBooks, if
you reference an online assett, there’s no indication of what should happen
in that case, and there’s no standard EPUB way to render that separate from
the flow of the book


rich: I am trying to figure out where the issues are with reusable
descriptions


jcraig: with details you’d have to use an SVG or an iframe to reference the
external resource


Ted: there’s two different kinds of sharing of description. In the case of
packaged content like EPUB; sharing the same description between multiple
content documents, and the description is also included in the EPUB. The
second case is the network one where you have two different books that
share the same description


dkaplan: taking no position with element or attribute is used, it is a
requirement for us that there is one way to do this thing. In publishing we
want to make it sustainable for content producers


… in a world where there are no ATAG compliant tools it is important to use
that it is simple


jcraig: I think my response to that is twofold: one I think it is possible
that we can get to a solution to one single method, the link is the only
way and it's worked in the Web for 25 years. Two, I dont consider the
absence of tools a shortcoming of the specs, I consider it a shortcoming of
the tools, and publishers have control over their own publishing tool
chain.


… you’re welcome to reference it via link and longdesc


<jasonjgw> With apologies, I need to leave to prepare for an upcoming
meeting.


tzviya: about authoring tools: I’ve seen many authoring tools that say
“fill in alt text here”, there are guidelines what longdescs should include
but no advice what markup to use


rich: one of the issues we need to look into is the whole personalized
showing and hiding of information. To me thats the combination of a media
query, and some content being hidden in the DOM by default


jcraig: I see that as a later step. Right now the base requirement is to
have descriptions that does not change the layout of the page. After we get
to that point, a follow-up requirement might be CSS support based on user
preferences. User preferences doesnt exist on any system, so that shouldnt
block progress


… we have to walk before we can run


rich: one of the things that was discussed was detail and summary, that
doesnt give us the remote content support


… providing a src attribute, is that a viable option


Ted: I think its very unlikely, given that details is shipping in browsers,
specced in a rec with a processing model


… its a huge change to the processing model thats very unlikely to be
supported by browser engines


jcraig: it would be possible to do it that way, do have it shown be
deafult, you can do that today with a user stylesheet


… having that happen via a stylesheet isnt necessarily the case, but one
could use a match media script [??10]


rich: we need to find out why the other browsers havent implemented details


jcraig: we dont need to wait on them, thats what polyfills are for


rich: publishers dont want to stick polyfills in books


jcraig: some publishers are using polyfills already, this would be a pretty
light one


rich: publishers, can you accept polyfills?


dkaplan: I dont believe Sanders is here, so speaking with my Safari Books
Online hat, publishers dont provide the platform. So from a publishing
perspective it comes down to browsers and reading systems


… it is acceptable if the reading systems would be supported


tzviya: we deliver to 50 retailers, maybe 5 accespt javascript


dkaplan: the question is can we get better support moving forward


jcraig: currently with browsers, details element is not supported in IE and
Firefox, but no one has objected so as far as I know they plan to support
it


tzviya: theres a big distinction between not supported and rejected


<tzviya> I would appreciated some help refining the requirements document
based on today's discussion


rich: I will talk to Microsoft about details, and talk to other vendors
about the src attribute


janina: we should start building the grid of options


rich: we have the requierements, we need to figure out what the best option
is and how to get it supported in browsers


avneesh: concern about details, more complicated than longdesc


jcraig: the publishers tool chain is at play there, the publisher can hire
someone to figure it out. If a publisher is including this content, they
write a toolchain to handle it.


avneesh: I am looking at the track record, where they couldnt even get
longdesc working


<LJWatson> +1 to the publisher's toolchain being a critical factor.


jcraig: good point, we are finding that most books dont even have alt text


tzvia: admits to finding alt text authoring challenging


Tom: we dont have trouble with alt text, we fond that its not going to work


judy: in the grid you are preparing, the considerations of feasibility of
use should be included


avneesh: similarly, high complexity in polyfills


Summary of Action Items
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/08/13 18:05:57 $





Rich Schwerdtfeger