See also: IRC log
<trackbot> Date: 05 February 2015
<George> Hello from George
<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus
<asurkov> btw I’m on the call
<asurkov> hey
<asurkov> hey :)
<LJWatson> [IPcaller] is me
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Feb/0006.html
<scribe> scribenick: clown
<richardschwerdtfeger> - Issue 690: aria-describedat
issue-690
<trackbot> issue-690 -- Implementor concerns for UA requirements in #aria-describedat -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/690
RS: First, we have some concerns
from browsers about user experience.
... But, what we should reivew is why the dbup have asked for
the attribute
... I've asked George K. to attend and share with us the
rationale and plans.
GK: We have included described-at
in epub 3.01 spec.
... In 3.0 as well.
... it could be put on a whole range of elements that need more
info for persons with disabilities.
... to further detailing. things like tables for pre-formatting
in braille.
... describedat meets the requirements of the "diagrammer" — a
vocab for graphical content.
<jongund> I can't get on the bridge
<richardschwerdtfeger> http://diagramcenter.org/
GK: diagrammer provides meta data such as age group, classes, and others
<jongund> The telephone bridge is full
GK: we have a tactile element,
along with a "tour" — how you would explore/feel the
object.
... Also an <about> element.
... we feel describedat would be excellent to point to an html
version of what the diagram centre would produce.
<danielweck> http://diagramcenter.org/standards-and-practices/content-model.html
GK: Also in the DAISY authoring
tool called "toby".
... can add these other descriptions using these authoring
tools.
<clapierre> Poet Image Description link https://diagram.herokuapp.com
GK: standard operating procedure
is not only provide alt text, but also longer
descriptions.
... we envision describedat being added during authoring of the
content.
<richardschwerdtfeger> GK: Pearson requires a longer description than is normally provided
GK: @longdesc has been
re-introduced, and may become a recommendation.
... but we also need longer descriptions for things other than
images.
... an example is an animation.
... described-at would help in doing this.
RS: What about SVG?
GK: We could include that in the content model.
RS: We do have it in the SVG2
spec as this point.
... The point: you want something that is cross-cutting: SVG
and epub.
GK: and html5.
RS: Has the community started to make use of it?
GK: Poet and toby have started to
create the content.
... Using describedat is likely not built into any reading app
yet.
... We have also used aria-describedby.
... But, because of how describedby is rendered — most of the
time we require longer descriptions include markup in the
descriptions.
RS: Can you tell us about the implementation in radium builds, and how that impacts the UX.
DW: We have not chosen a UI
affordance to expose describedat.
... We run on desktop platforms and others.
... For example, Mozilla has a menu item in the context menu
for longdesc.
... But, we likely won't use that.
... Approach is to divide the work.
... How to handle all three attributes.
... And, how to present the content they refer.
... We have the primary reading flow, and then branches to the
descriptions, and then go back to the primary.
... We will leverage the epub features.
... We haven't looked at all the UI options for the
descriptions.
... But, we don't want any visible interference in the primary
flow for the describedat descriptions.
... It is not going to be an AT feature, but available for all
users.
<richardschwerdtfeger> a?
GK: We feel the supplemental
material provided by the diagrammer would be useful to
everyone.
... Many times the descriptions are written by experts.
... example: a physics diagram done by a physics professor.
CL: Daniel and I spoke at a
hackathon and discuss the UI options at length.
... They are currently exposing describedby in an epub document
by hacking it to look like a describedat.
... But it is a hack, so a better solution would be
better.
... We really want the describedat feature.
RS: What platforms that you are building book readers in?
DW: Javascript or ??
... Native apps on android, iOS, windows, etc.
... Chrome extension on the chrome web store.
... And a cloud reader.
... Cloud reader is cross platform and cross browser app.
<richardschwerdtfeger> Readium cloud reader: http://readium-cloudreader.divshot.io/index.html
DW: It has a broad space. That's
why we want to implement the features in the JS core
library.
... Even native apps would then use the JS core.
JC: First, this is a solution in search of requirements.
<jcraig> These are requirements for being able to associate a description with any type of object. They should not have been requirements for any particular solution. Even the agenda topic and document names are leading. "requirements for longdesc" and "requirements for describedat" are a solution in search of a problem.
JC: Req's for longdesc,
aria-describeat are for a solultion.
... We should be defining the problem.
... We don't have a way of providing these descriptions, but,
in fact, we do
... There are features of html that can do it.
... describedat/longdesc are not the best approach.
... This is not a primary interface,.
... As such it will be sidelined and will require authors go
out of their way to provide a11y instead of getting it for
free.
... A standard link would be more universal.
<LJWatson> +1 to this not being a primary interface.
JS: Are you saying content needs to be authored differently.
JC: Any content that need
descriptions should be authored using a mechanism that anyone
can use. For example, a link.
... We need an API for webgl.
GK: One requirement: People will
stub in a description.
... Then other organizations could add other information.
... It will allow addtions to the external resource, and could
be built up over time.
... There may be more than one links going out in a complex
book.
... Publishers want something that won't disturb their pristine
content.
JF: First, +1 to what GK said about what should be on the page.
<jamesn> MichaelC - any way to increase the meeting size?
JF: Daniel, you mentioned that FF
exposes the longdesc in the context menu.
... But, you don't think that's the way to do it.
... What do you suggest for sighted users to see that there is
additional info?
DW: We're not sure yet. It is
still under discussion.
... Touch interfaces are not good with respect to menus.
... It could be a different UI on desktops
... We haven't explored how keyboard access is involved
here.
... either with or without a screen reader.
... Also, challenges around pagination. Browsers scroll the
page.
... Because of all these combinations, we don't know what the
best solution.
... Maybe we choose different UIs for different platforms.
JF: The argument is that finding
this content is like an easter egg hunt.
... As a sighted user, how do they know that this material is
available?
DW: Obviously need some sort of
visual hint.
... Should it be persistent, but not inserted into the content
to preserve pristine content.
<clapierre> forgot me?
<Zakim> jcraig, you wanted to talk about Pearson, since its been brought up several times. and to respond to the "publishers" comment and to respond to the "publishers don't want plain
JC: I'm confused by claim that
publishers do not want links.
... Maybe it's because of the blue-underline.
<jcraig> http://cookiecrook.com/longdesc/details/
JC: But you could style it any
number of ways.
... People have mentions pearson (?) and "publishers need
this".
... We replied to tell those publishers to talk with their
apple reps, and get them to say why they need longdesc.
... we set up conferences, and asked them why?
... Their reply was that they didn't know, but were told to ask
for them.
... We have any number of new features coming down the line in
html.
... Longdesc and describedat are old solutions.
... They are not the best way to do it now.
... There are ways to make even raster graphics accessible
now.
<jcraig> http://cookiecrook.com/longdesc/
<jcraig> Longdesc (and describedat) alternatives in HTML/SVG/etc. http://cookiecrook.com/longdesc/
JC: These are other ways to
handle longdesc without using longdesc itself.
... These are available today.
LW: see below:
<jcraig> scribe: jcraig
<LJWatson> James and John covered most of what I wanted to say. I would like to reiterate that I don't think @describedat is a good solution because it takes on too many of the flaws in longdesc. We should revisit the problem, identify requirements, then start looking for a solution.
<jamesn> I am not on the call but I believe the examples at http://cookiecrook.com/longdesc/ were tested by someone on a bunch of AT and none were as well supported as longdesc
<mattking> +1 to LW
<mattking> I want everyone to see the accessible content.
<mattking> no hidden accessibility.
<LJWatson> +1 to Matt K
<joanie> +1
CL: agree in principle for having descriptions in content, but if there is more than one external description in content, there is no way to do content negotiation
<richardschwerdtfeger> +1
CL: need multiple describedat values with media types (3d model, tactile, about, etc)
JC: longdesc and describedat don't solve that problem.
<richardschwerdtfeger> Rich: we don’t support that at the moment
<MarkS> Not on call but wanted to say that visual encumbrance is a real thing and needs to be considered. Sometimes content for one audience is confusing for other audiences. There should be a way of targeting content for specific audiences. This is why offscreen text is so very very popular in web dev today.
<JF> +1 to MarkS
JF: re: details element, we can
do some today, but we also add <nav> instead of just
<div role="nav">
... real use cases for a native(?) way to associate an external
description
... longdesc, etc reduces code
DW: content is often delivered inaccessible, what I heard is that you can insert content into main body
<JF> not only does longdesc [sic] reduce code, it is use-specific and can be more easily and acurately mapped to a specific pre-defined function/feature
DW: longdesc/describedat could
then only be presented by reading systems to the users that
needed it
... some publishers embrace new web tech for collapsing addtl
descriptions, but some publishers hate doing that because it
disrupts the pagination, etc.
RS: d-links are not an option
(jc: no argument here, those things were ugly)
... need a option that does not disrupt in svg and other
sources
... our spec can't safely define how a UA should render
desscribedat in a mainstream user agent case
... b/c UA manufacturers have stated that's not an option to
define the user interface in a tech spec
... describedat by default does not define mainstream UI
<Zakim> janina, you wanted to say there are several "authors" in the production process
<mattking> scribe: mattking
Janina: We need to consider that
authoring is distributive; primary authors + other authors for
accessible content
... tactile graphic info will not be done by primary
authors.
... some of this content may be authored post-print.
DW: about need to ref diff types
of descriptions, what we envision is using describedat to ref a
single document.
... We are looking at enabling the filtering for different
users within the single external document
... this is still experimental; could utilize media queries. to
identify correct descriptive content for the specific
user
... or for correct modality.
JF: The track element requires
author to provide the JS to activate the captions
... This is another real world example of how we do not use
ARIA to mandate the UI.
... This is not an issue for track.
RS: the current spec does make rendering requirements for track and that was an issue.
LW: I am concerned abut the UX from having the user making modality choices inside the external descriptive doc
Janina: not sure it is intent user would make the choice.
DW: it may be teh case initially that user makes choice but eventually would like it to be automatic
GK: agree with LW concern.
RS: Alex what are your thoughts as Mozilla rep?
Alex: I am not against the
feature; I see the use case. It does make sense that it have
some UI.
... I am concerned about the naming
<clown> http://w3c.github.io/aria/aria/aria.html#aria-describedat
Alex: It should not be
aria-describedat if it has UI; should just be
describedat.
... aria is about semantics
RS: aria is about
interoperability
... is the current design of describeat enough?
Janina: there is a need for a way to define required metadata
RS: if we put content in doc, then it disrupts flow.
<JF> +1 to "D-link is fugly"
RS: do authors need way to override rendering of describedat?
<richardschwerdtfeger> scribe: rich
<richardschwerdtfeger> mattking: I am hearing that the authors don’t like the fact that the readers are taking control of the rendering
<richardschwerdtfeger> mattking: if the authors don’t take responsibility then the readers take responsibiliity
Janina: Yes, that is correct that author loses control.
<clapierre> +1 to author's giving up control
<richardschwerdtfeger> scribe: mattking
DW: The nature of current model
we have never shied away from idea that the reading system is
in charge of the UX
... Not all the reading system features will neecesarily make
their way to mainstram browsers
RS: I think we need to get some publishers on as well.
Janina: agree
RS: this is going to take more
time to work out.
... there is a wholesale shift toward user context specific
delivery
... we will see ths especially with mobile
<fesch> +1 on what RS said
JF: What DW said is critical about auser profile preference
<richardschwerdtfeger> q/?
<Zakim> JF, you wanted to say that the reader/end user MUST have final say
JF: by having a use-case specific attribute, we can target specific users. That is a way of handling the visual purity vs added functionality.
<clapierre> +1 on Jim's comments
RS: Who should we ask from the publishing community
George: We have edupub conf
coming up.
... Pearson is definitely one, maybe Wiley too
<clapierre> I would reach out to Tzviya who is with Wiley and is the DPUB chair.
<danielweck> Tzviya Siegman
<richardschwerdtfeger> http://corporate.harpercollins.com/us/press-releases/419/
RS: Harper moving to epub and
using open source
... George do you know specifically who we should contact?
<clapierre> Benetech did an accessibility assessment of HC's epub3 work just recently.
George: yes
<fesch> s/Harpeer/Harper/
George: I can get you names/addresses
RS: This has been helpful.
... thank you everyone for coming. I really appreciate it.
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/epbu/epub/ Succeeded: s/pristince/pristine/ Succeeded: s/available./available?/ Succeeded: s/DW/GK/ Succeeded: s/Pierson/Pearson/ Succeeded: s/Harpeer/Harper/ FAILED: s/Harpeer/Harper/ Found ScribeNick: clown Found Scribe: jcraig Inferring ScribeNick: jcraig Found Scribe: mattking Inferring ScribeNick: mattking Found Scribe: rich Found Scribe: mattking Inferring ScribeNick: mattking Scribes: jcraig, mattking, rich ScribeNicks: clown, jcraig, mattking Default Present: +1.703.978.aaaa, George_Kerscher, +1.609.759.aabb, JF, Joanmarie_Diggs, +1.408.979.aacc, janina, clapierre, James_Craig, Jason_White Present: +1.703.978.aaaa George_Kerscher +1.609.759.aabb JF Joanmarie_Diggs +1.408.979.aacc janina clapierre James_Craig Jason_White Found Date: 05 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/05-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]