W3C

HTML Accessibility Task Force Teleconference

14 Aug 2014

See also: IRC log

Attendees

Present
Sam, Chaals, Liam, janina_, Plh, Shane_McCarron, paulc, Cynthia_Shelly, [IPcaller], John_Foliot, Rich_Schwerdtfeger
Regrets
Chair
Janina
Scribe
liam

Contents


<trackbot> Date: 14 August 2014

MAUR Heartbeat

Janina: heartbeat: a document was published yesterday ...

<janina_> http://www.w3.org/TR/media-accessibility-reqs

<MarkS> regrets Mark_Sadecki

expecting one more set of edits, editorial

then media subteam believes document should be ready to move forward later this yer to Note status

Longdesc

Janina: good news, we have a CR document published

pointer is in the agenda

we have to move forward quickly to stay in sync with HTML 5

we're expecting a formal objection but not yet received

next step is moving to PR

we should review expected timeline

we should also talk about requirements for moving from CR to PR

<paulc> See Sam's reminder to David Singer about timing of longdesc: http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0021.html

we need to show that each of our MUST statements is supported in 2 independent implementations

we believe we have that

bu [impl'n report] may need to be clearer

agenda for this call: http://lists.w3.org/Archives/Public/public-html-a11y/2014Aug/0018.html

<plh> https://www.w3.org/2014/08/longdesc-todos.html

plh: due to the timeline of html5, 'cos we want to release HTML 5 during TPAC ...

we have to issue a cfc during CR to move to PR, rather than after the CR ended, but we don't have time

so we have to issue the implementation report ready in time to issue the cfc

report to be ready by next wednesday (20th)

current impl report: https://rawgit.com/w3c/web-platform-tests/master/html-longdesc/test-results.html

chaals: I can probably get a document over the weekend that will have just the result we need
... we have a list of tests, I can fish up that list

nine tests

cover MUST requirements for user agents

Janina: are there MUSTs for other things than user agents?

chlls: we only need to show results for browsers

plh: multifunction api exposure test result table has 6 columns

and it's testing IE11, FF, chrome, safari, icab, with 2 different stacks

so how many impl'n do we have?

chaals: so what is actually missing is DOM exposure

we need to update this table

the MSAA on Win is the standard accessibility API for a lot of stuff, still

we don't seem to have mac support

[qualitative statement unminuted :-) ]

plh: so just exposing longdesc in the DOM is enough to claim implementation?

chaals: [scribe could not hear]
... [exposure to DOM is sufficient for API exposure]

plh: along with those tables we need some explanation on how to interpret the tables

as we're going to have to repeat the explanations to the director

[chaals will add information to help understand what the tables mean]

<chaals> [What we should do: Make a document that has a table of the things we need to know, with an explanation, and then link to this document for more information for those who are interested]

janina: we have a lot of data here not relevant to meeting the reqs of a w3c spec; we find it interesting but not [pertinent]

[ok, 3pm ET/2100Alice Springs Time, IRC meeting for editing]

Liam notes Laura reopened her issue

<chaals> [If it is normative change, then it won't happen and has been resolved by the group. If it is editorial (as I think) then it is neither here nor there and we can try to make her happy if we think it is important]

<chaals> [I don't think the level of change is problematic. But the statement she is asking for is untestable, and therefore I am not that interested in applying it]

janina: increased accssibility is subjective

and implicit

jf: mostly editorial, agree, with Charles

<chaals> [I am in favour of not doing anything to what we have]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24168

<chaals> [+1 to Shane]

shane: we're giving this way more weight than it's work, it's a dead horse

<chaals> Proposed Resolution: We will not do anything with this editorial suggestion...

decision: close 24168, resolution, no action

<chaals> [i.e. we can make it wontfix, if we want, or just tell the director what we are doing with it]

Picture Element Alt http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#an-image-in-a-picture-element

janina: we have proposed language from steve

are we satisfied with this language?

Resolution: accept steve's language on picture

ARIA 1.1 and HTML 5 -- Do gaps remain?

[i.e. no action required from TF]

[required people not present]

Access Key/Command

Rich: we need to find out, are there any additional things that must go into aria 1.1 to support html5 native host language semantics

I'd like to wrap up a lot of the issues for 1.1 and start working on v2, start building test cases

<chaals> [There is an issue (IMHO) about whether ARIA should work with native UI - or alternatively define what the assistive technology that it deals with is, and isn't]

Janina: [agrees with Charles]

Rich: what do you mean by native UI?

[the browser]

JF: longdesc is being exposed right now but no visual rendering in the browser UI

<chaals> [If ARIA only works through an Accessibility API, we effectively get two different interactions dependent on the arbitrary detail of whether the user's tools rely on that API or the user relies on a browser and its native functions]

should we start looking for ways of exposing this functionality to more than screen readers?

<chaals> [… and that's a pretty unpredictable situation for a user to be in]

Janina: we're starting to build use cases, including from digital publishing

Rich: dpub IG wants to supply structural semantics in aria markup and have it be dual purpose, can be exposed for accessibility & for epub readers,

but want to define semantics for e.g. comic scripts with embedded SVG

but we don't say what [browsers] do with it

CS: Microsoft would like to use ARIA to impact UI

<chaals> [We *allow* them to use ARIA on UI already…]

Rich: ARIA has enough uptake now, advantages in browsers using it to influence the user experience

Janina: how o we manage having the browser & a11y API both using aria?

CS: We've been looking at allowing more scriptability from within JavaScript

<chaals> [Actually, the hard bit is how do we specify what should be done without over-constraining the UI to the point where we mandate suboptimal behaviour]

<chaals> [e.g. the definition of how to interact with native semantics - strong vs weak etc - is part of this work]

[e.g. a11y api being able to manipulate the DOM, and scripts being able to talk to the a11y API]

Rich: that's an ARIA 2 thing, need more consistency in APIs across platforms

e.g. control pattern

Need to pull out use cases

roots of why we made ARIA were based on UI widgets in current practice at the time, it's gone way beyond that

seems silly not to make use of it

CS: a lot of things like screen size changes, audio interfaces, are much more mainstream now, not only a11y

Rich: mobile is levelling of paying field across the board

Janina: so this is going beyong 1.1, but we're trying to wrap up 1.1 for html5

1.1 needs to move towards test cases so we can be publishing something in a little over a year

this has been a fundamental conversation, we need to start adding use cases

CS: it may be this goes into web events or UI spec

Janina: as long as we dont lose the a11y we fought so hard to build

[agreement]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/08/14 16:37:17 $