minutes: February 5, 2014 WAI PF ARIA Caucus

Draft minutes are posted at the following URL and follow my signature in 
plain text.

http://www.w3.org/2015/02/05-aria-minutes.html


Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com

W3C <http://www.w3.org/>


  - DRAFT -


  Protocols and Formats Working Group Teleconference
  05 Feb 2015

See also: IRC log <http://www.w3.org/2015/02/05-aria-irc>


    Attendees

Present
Regrets
Chair
    Rich
Scribe
    jcraig, mattking, rich


    Contents

  * Topics <#agenda>
     1. aria-describedat <#item01>
  * Summary of Action Items <#ActionSummary>

------------------------------------------------------------------------

<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

<https://lists.w3.org/Archives/Public/public-pfwg/2015Feb/0006.html>

<scribe> scribenick: clown


      aria-describedat

<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

<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.


    Summary of Action Items

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015-02-05 18:54:45 $

------------------------------------------------------------------------


    Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

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

WARNING: No "Present: ... " found!
Possibly Present: Alex CL DW Fred GK GVoice George George_Kerscher 
IPcaller JC JF JS James_Craig James_Nurthen Janina Jason_White 
Joanmarie_Diggs Joseph_Scheuhammer LJWatson LW MarkS Matt_King P19 P2 P21 
P7 RS Rich Rich_Schwerdtfeger Susann_Keohane aaaa aabb aacc affect aria 
asurkov bgaraventa1979 clapierre clown comment danielweck design fesch 
https jamesn jcraig joanie joined jongund links mattking mgylling 
richardschwerdtfeger scribenick their to trackbot visual
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

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
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>
diagnostic output]