See also: IRC log
<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
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
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??1/Bontrager/ Succeeded: s/UN/Un/ Succeeded: s/Gallia??2/Igalia, ARIA spec co-editor, developer of the Orca screen reader/ Succeeded: s/I dont see how thats possible if we dont have browser support/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"/ Succeeded: s/joanie: 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 the crux of what we need to solve, is whats rendered and where that choice gets made/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.../ Succeeded: s/right/right. user CSS, browser GUI, or OS GUI./ Succeeded: s/??/Tom_Starbranch/ Succeeded: s/joanie: is that an ir/léonie: is that an ir/ Succeeded: s/an get to a solution to one single method, the link is the only way./an get to a solution to one single method, the link is the only way and it's worked in the Web for 25 years./ Succeeded: s/Two, I dont consider the absence of tools a shortcoming of the specs, I consider it a shortcoming of the tools/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./ Succeeded: s/be support/be supported/ Succeeded: s/detauls/details/ Found ScribeNick: mgylling Inferring Scribes: mgylling 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 Found Date: 13 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/13-aria-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]
