W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

20 Aug 2015

See also: IRC log

Attendees

Present
Janina, paulc, LJWatson, Joanmarie_Diggs, Judy, IanPouncey, Rich_Schwerdtfeger
Regrets
Chair
Janina
Scribe
Judy, LJWatson

Contents


<trackbot> Date: 20 August 2015

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

<janina> trackbot, who's here?

<trackbot> Sorry, janina, I don't understand 'trackbot, who's here?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<janina> OK, Shane, thanks!

<scribe> scribenick: LJWatson

Agenda Edits & Additions

Meeting Next Week? -- Janina

JS: I won't be available next week. Any objections to skipping for one week?

JB: It's W3C Geek Week, so less availability from W3C staff too.
... Do we have any pressing work?

JS: We'll cancel the call.

Canvas 2D Level 1 Progress -- Rich, Mark, Janina, Paul, PLH

<Judy> All: No one responds with any urgent work.

RS: We have a timeout issue in the testing scripts.
... Have reported a couple of bugs to Dominic.
... Have updated the bug information as requested by Paul.

JS: Do we know when PLH is back?

RS: Also asked Mark s for time to look at the test harness, since he created it. Waiting for a reply.

JB: PLH is back next week.

Transcript Support Update -- Chaals

JS: Suspect nothing to add without Chaals.

HTML Details & ARIA Describedat -- Rich, Janina

JS: There is a desire from the dPub IG to be able to annotate any element in an HTML page (HTML is used in eBooks). @longdesc doesn't quite meet their use cases, but it's close.
... The ARIA is doing due dilligence on possible solutions that may not require changes to the ARIA spec. Like <details> for example.
... Would be important to add @src to details> for this to work.
... Minutes from the ARIA TF call last week are above (in the agenda item).

RS: We don't really need the @src in <details> because you can put an <iframe> inside <details> and this can take @src.
... We have everything from a plumbing perspective, in <details> and <summary>.
... There is a visibility issue, but we'll need input from CSS WG to address that.

<richardschwerdtfeger> https://twitter.com/stevefaulkner/status/634264772981182464?t=1&cn=bWVudGlvbg%3D%3D&sig=4b68c2da98a356db7d67140c6d0c5fb718b3b06a&al=1&refsrc=email&iid=855db08bdcc343068fa1b533db13e2e8&autoactions=1440055481&uid=16903091&nid=4+1489

RS: MS has said they don't like the UI (taken from the tweet linked above).

PC: Who were you talking to at MS?

RS: Rob Sinclair. We have a follow up meeting next week - but these meetings go beyond the <details> and <summary> conversation.

PC: Suggest that conversation continues.

rresgent, make minutes

RS: Mozilla is just a matter of back/forth about how to implement this solution.
... Posted the bug to the ARIA TF a while ago. Can't find the link right now.

JB: Is this something where direct discussion might keep us from an "incident loop"?
... Based on the TF call it seems that details/summary was well received, but if it isn't liked by other implementors...

RS: I need to identify the reason why other implementors haven't implemented it yet.
... We have two implementations of details/summary, but that isn't enough for this.

JB: We have already invested massive amounts of time on @describedat only to find serious objections from one particular implementor.

RS: One thing @describedat does not do is make itself available to all users.

+1 to Rich on availability to all users.

RS: If we discover details/summary isn't viable, we may have to go back to @describedat though.
... I want to exhaust other possibilities if I can first though.

<Zakim> janina, you wanted to talk about hidden vs visible details, html history vs dpub req

JS: Trying to recall the history behind the visibility of details/summary.
... Recalling the table summary discussion.
... One complaint against table summary was that it was hidden to all except certain AT users.
... When talking to dPub, there was a requirement for the mechanism to be hidden from view by default.
... So now we're looking at a media query that would intentionally keep something hidden by default.

RS: <details> is an HTML element that represents a common pattern - a button that opens/closes content. If it isn't visible, how do you know it can be clicked on?

JB: Discussion a couple of years ago, about the auxilliary benefits for people with disabilities other than sight related.
... There was support for the ability to make such things visible.
... The need for content to be available to everyone comes up against the requirement of discoverability.
... If you find a details/summary widget, how do you know it contains a description?

<Judy> scribe: Judy

Leonie: Isn't that what hte summary element would do, would in partnership with details
... to let you know that's the info that's there

<LJWatson> RS: The publishers would have to put something in the book to indicate more information was available.

<scribe> scribe: LJWatson

UNKNOWN_SPEAKER: It almost has to be under author control. This was another issue with @describedat - dPub didn't want the UA to be responsible, especially not through plugins.
... So we could use a CSS media query to render the details/summary widget visible (or not).
... Apple suggested the possibility of an OS level setting that could be turned on, to say "I want additional information to be visible when it's available".
... So it's under user control.

JB: That's more for the developer to implement?

RS: Yes.

JS: We'll need good authoring support.
... We're also looking at using ARIA roles to help with disambiguation.

RS: Yes, but we really need to move fast on details/summary to hit the ARIA 1.1 schedule.

JS: A resolution people can live would be good.

Alt Doc Update -- Shane, Liam

JS: No update without Liam or Shane. Scheduled for next week though.

Tab Panels Update -- Leonie, Et Al

LW: Nothing to report

Web Payments Accessibility Followup

JS: The Web Payments people asked us to review their proposed charter.

<Judy> scribe: Judy

<janina> http://lists.w3.org/Archives/Public/public-html-a11y/2015Aug/0022.html

Leonie: there was mention of the benefits of avoiding market fragmentation
... accessibility could be added to that list
... we could change that to "...accessible user experiences"
... and in section 3.2 optional deliverables, recommended (car?) payments @@
... could mention digital debit pool accessible to users

[these are in the LJW's email]

<scribe> scribe: LJWatson

JS: Think those are nice suggestions.

JB: Who'll send them over to WG?

JS: I can bundle them up and send them over.

LW: Think the AC charter review ends in the next week or so.

JS: We also need to think about user requirements.

Bug Triage -- Leonie

LW: Nothing to report.

TF Open Actions http://w3.org/wai/pf/html/track

JS: Can someone open the actions?

LW: As I recall the people with open actions are not on the call.

PC: 9 open actions.
... They're all on Cynthia, John F, Chaals and Steve F.
... Several are overdue or will be by the time of our next meeting in September.

Other Business

be done

JS: No meeting next week.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/08/20 15:47:27 $

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/ehaust/exhaust/
Found ScribeNick: LJWatson
Found Scribe: Judy
Inferring ScribeNick: Judy
Found Scribe: LJWatson
Inferring ScribeNick: LJWatson
Found Scribe: Judy
Inferring ScribeNick: Judy
Found Scribe: LJWatson
Inferring ScribeNick: LJWatson
Scribes: Judy, LJWatson
ScribeNicks: LJWatson, Judy
Present: Janina paulc LJWatson Joanmarie_Diggs Judy IanPouncey Rich_Schwerdtfeger
Found Date: 20 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/20-html-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]