See also: IRC log
<trackbot> Date: 14 August 2014
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
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]
janina: we have proposed language from steve
are we satisfied with this language?
Resolution: accept steve's language on picture
[i.e. no action required from TF]
[required people not present]
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]