W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

10 Oct 2013

See also: IRC log

Attendees

Present
MarkS, [IPcaller], +1.716.842.aaaa, aardrian, Leonie, Plh, Judy, Janina, Cynthia_Shelly, David_MacDonald
Regrets
Chair
Janina_Sajka
Scribe
Léonie Watson

Contents


<trackbot> Date: 10 October 2013

<janina> Meeting: HTML-A11Y Task Force Teleconference

Identify Scribe http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

<scribe> scribe: Léonie Watson

scribenick LJWatson

Everyone should rejoin the HTML-WG http://lists.w3.org/Archives/Public/public-html-a11y/2013Oct/0001.html

JS: Everyone needs to rejoin the TF. The HTML WG rechartered, and to participate in this TF everyone must be a member of the WG.

<MarkS> Current Members of HTML WG

AR: Does re-joining the WG automatically re-join the TF?

JS: Yes, I believe so.

JB: We had some trouble with this before. Someone de-bugged it, perhaps Michael?

MC: Everyone on this call, seems to have re-joined the WG already, so we're in good shape.

CfCs on Revised Work Statement and Decision Procedures

JS: PF had rejected the previous process policy the TF put forward, but I believe PF is now agreeable to the current proposal.
... PF wanted the role of the teleconference to be more clearly spelled out.

Longdesc Testing CfC http://lists.w3.org/Archives/Public/public-html-a11y/2013Oct/0020.html

JS: The WBS on the tests didn't get a lot of response, as Chaals noted. The tests were accepted as sufficient though.

MS: We're continuing to test and record results.
... We're still accepting results if anyone wants to add/confirm.

Longdesc LC Comments

JS: We were hoping we'd be in a position to call for concensus at this meeting, but we're not quite there.

<MarkS> Preliminary Longdesc testing results

JS: There has been a lot of QA activity in recent days, but the TF chairs weren't able to come together to sign off in time for today's telecon.
... The CFC will be twofold - both for the extension, and for some editorial changes.

Alt Edits Review

JS: We had a response from WCAG to look at section 4.8.1.1 of the spec.

<janina> http://lists.w3.org/Archives/Public/public-html-a11y/2013Oct/0030.html

JS: Essentially they're signing off on that section being appropriate.
... Not sure about the first item still, but would like Steve to be here for that discussion.

MSE Review http://lists.w3.org/Archives/Public/public-html-a11y/2013Oct/0018.html

MS: Janina and I went through the spec. It's highly technical, and so we're taking the approach of going thrugh the user requirements that the TF has developed previously.
... In our reply we're asking whether those requirements have been met by the MSE ( = Media Source Extension) spec.

JS: We introduce complexity when we introduce alternates - text, captions audio description etc.

For example a text transcript may take longer to consume than the video content itself, where does responsibility for pausing the video lie?

MS: They are thinking about these things in the spec, which is encouraging.

JS: We *think they're thinking about them.

<Judy> Link to the spec under discussion, for those interested: http://www.w3.org/TR/media-source/

<Judy> Geoff Freed from National Center for Accessible Media (NCAM)

Geoff Freed from National Center for Accessible Media (NCAM) may not be able to help with a thorough review before the deadline, but he may be open to helping with specific things.

EME Review

DM: The spec defines an API. There didn't seem to be anything too "scary" in there to me.

<MarkS> DM: I took a look at it and it appears to just be about how the API's will talk to each other.

CS: The code you write as a developer calls the API.

DM: Is there a way that someone making an API like this could interfere with the accessibility APIs?

CS: Haven't looked at this spec, but in this case I don't think it's likely.

JS: We're sensitive to this because of the eBook scenario, in terms of enabling people to access content, but we're not dealin with that kind of media here.

CS: We should ask whether any text output will be available to the accessibility APIs, but that's about it.

PLH: Not always. In some cases the content is pinged directly to the screen.

CS: So whatever does the rendering has to make the content available to the accessibility API.

AR: Is it possible to factor that into the spec?

CS: If the browser renders it, the browser has to make it available to the accessibility API. If it's a third party renderer, the responsibility lies with them.

PLH: This is an idea worth reporting back to the spec WG.

JB: Even if there is a 1% chance that encryption could be applied to accessibility information, we need to address that.

AR: We need to be sure that alternate textual information is being exposed to accessibility APIs.
... + in a non-encrypted manner.

PLH: David, what do you mean by audio description?

<MarkS> <track type="description">

Example audio description clips: http://www.rnib.org.uk/livingwithsightloss/tvradiofilm/television/adtv/Pages/ad_clips.aspx

JB: We should be aware of the granula requirements we developed through the media sub-team.

CS: Don't expect this to be too controversial.

MS: Do we know whether the spec covers anything beyond the media stream?

PLH: Yes, that's the point.
... Very often the tracks will be part of the same file sent to the UA.
... Not in the majority, but in some cases at least.
... Simply asking the question will be a god start.

AR: Clarification on my earlier point - the EME needs to make sure the alternate content needs to expose the information to the accessibility APIs.

CS: Not sure that's quite the right approach.

<aardrian> I am saying that any EME APIs must expose alternate content within the API

<aardrian> From there, it can be picked up a11y APIs.

Subteam Reports: Bug Triage; AAPI Mapping; Media;

<MarkS> LW: but triage hasn't met in awhile. no new bugs that aren't already being taken care of my steve or chaals (longdesc)

<MarkS> …there are a fair number of bugs that are marked as resolved that will need to be reviewed by the TF

<MarkS> JB: would it make sense to visit TF with these questions so that you can walk people through the list.

<MarkS> LW: yes, we can do that.

<MarkS> JS: we can section off some time for upcoming meetings to begin walking through these then.

HTML 5.1 Objectives http://www.w3.org/WAI/PF/HTML/wiki/51wishlist

<MarkS> 5.1 Objectives

JS: We have a wiki page of points under discussion. It's a living list and additions are welcome.

MS: We're looking at other specs to see how HTML5.1 could better support them, or be supported by them.
... Talked about reaching out to other WGs.

DM: Like WCAG?

MS: Sure, WCAG, ATAG etc.

JS: PF will be focused on ARIA 1.0 so our attention is limited for other activities, but after that we'll be open to syncing up.

Other Business

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/10/10 16:00:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/MSC/MSE ( = Media Source Extension)/
No ScribeNick specified.  Guessing ScribeNick: LJWatson
Found Scribe: Léonie Watson
Default Present: MarkS, [IPcaller], +1.716.842.aaaa, aardrian, Leonie, Plh, Judy, Janina, Cynthia_Shelly, David_MacDonald
Present: MarkS [IPcaller] +1.716.842.aaaa aardrian Leonie Plh Judy Janina Cynthia_Shelly David_MacDonald
Found Date: 10 Oct 2013
Guessing minutes URL: http://www.w3.org/2013/10/10-html-a11y-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]