Protocols and Formats Working Group Teleconference -- 05 Feb 2015

<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

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

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.

- DRAFT -

Protocols and Formats Working Group Teleconference
05 Feb 2015

Attendees

Contents

aria-describedat

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Protocols and Formats Working Group Teleconference 05 Feb 2015

Attendees

Contents

aria-describedat

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference
05 Feb 2015