HTML Accessibility Task Force Teleconference -- 02 Jun 2010

<trackbot> Date: 02 June 2010

<scribe> scribe: janina

john: let's start with open actions review
... judy's actions?

judy: have been working on a comparison to iso, seems orthogonal
... will post my conclusions
... so complete on iso comparison, but not on checking with other key individuals
... also unsure how to engage external people effectively without overwhelming them
... while action wasn't recroded, i did some work on the disability language in the doc, and will still complete that

john: is frank here?

[silence]

requirements document review

john: john: not sure how to break our log jam and move forward
... much media will be pushed via the net, whether via specialized ua, or a general browser, our doc is important
... we don't have the luxury to continue debating the doc, though
... our survey was to make sure our doc is complete
... think going through the doc detail by detail is premature

eric: perhaps i misunderstood what our purpose was in these requirements
... i understood that these would be required of any ua that implemented html5 media

john: my understanding, from the a11y side, is to fully participate in consumption of this media

<MikeSmith> I think other implementors are liking to view requirements in the same way that Eric just described -- as implementation requirements

john: for instance, sign-language differs from country to country
... it'll be a tricky balancing

shawn: i think a lot of our requirements aren't technically difficult

eric: not so sure
... hard to decode on small platform

shawn: but there are other ways to achieve this

janina: we need it in the spec so that it can be covered

eric: but, even on the desktop smil2 is lots of work
... so not necessarily easy to do
... are these rfc2119 musts?

shawn: not necessarily that we need smil, but that we need the ability to do these things

judy: we specifically separated user needs to avoid this conundrum

eric: but we need to discuss what is required

judy: absolutely agree

eric: my concern is that 'requirement' rfc2119 'must' on the user agent

john: i think everyone here is realistic
... we should remember the concept of "graceful degradation"
... yes, going back to the described video example, it's a balancing thing here too
... some kind of switching mechanism may be needed between a generalized broser and a more specialized player ua

janina: it's a question of what html5 wants to be, if a rich media platform, all these requirements will be needed somewhere, though probably almost never on any individual content item

<Zakim> Judy, you wanted to say that's why we separated out what the user needs vs how they can be technically achieved, so we wouldn't go into that

judy: we keep hearing the question of whether we need to prioritize these
... should we discuss prioritization?

john: also my question in some ways
... a bit disappointed in so few responses

<Zakim> MikeSmith, you wanted to say what we ultimately need in regard to the spec is a specific (sub)set of requirements for HTML UAs

mike: i think eric's response will be typical of browser developers
... the spec provides conformance criteria
... if there are requirements on something other than browsers, then it's not about html

janina: i can support rfc2119 should, but the spec needs to comprehend most of these because the intent seems to be a full gammut of media hosted via html

john: so our experience to date has been that addons and plugins may play something launched from the browser
... expect the browser will be more limited janina: not sure that browser may need to drive it all

judy: want to raise a different point ...
... want to come back to the question of what will help move forward
... only one person on this call has filled out the survey, so can we ask a new deadline for survey?

john: so, is this a wrong understanding of where we're headed?

eric: what?

john: html
... is should language overly onorous

eric: seems we want interoperable content on the web, so a spec that all user agents that most people use will implement

eric; so description of any feature in the spec needs to be so well described that it will be implemented consistently

shawn: but it's about how we capture author intent, not how user agents provide it
... roughly the same way sounds ok, but not exactly the same way my competitor does

eric: so spec doesn't say how to do some thing, but what it should do
... so external file format needs specification

john: so, eric, you mentioned multiple audio streams unsupportable on some devices today
... so maybe not today, but who knows about a year from now? I recall touch interfaces were experimental just a few years ago
... we just don't want today's device limitations constrain our specification of what's needed

shawn: so there's an issue of balance between providing the data in a form that something can be done with it
... so that's authoring--give the data in a usable way
... the must of what the content supports
... and the should of what the ua does
... we need to capture the musts

john: agree

janina well said

john: do we have agreement of where to go with this?

silence -- taken as ascent

john: so, judy ...

judy: i expect so few have completed the form because there's so much to do in completing it

shawn: will do, but want weekend

janina: ditto

kenny: end of today

john: by monday

mike: don't plan to respond

michael: don't feel qualified on this

judy: monday is better for me

john: so can we extend this until monday?
... and we need to send around another explanation that we want to capture user requirements

<Judy> +1 to accept input via email as well

janina: extend to 23:59 boston time monday

john: so we should have more complete results next wednesday

<Judy> janina: not sure that's the correct breakdown

<Judy> ...Sean Hayes helped us understand constaints around the authored requirements

<Judy> ...the must part might be on what the spec provides

<Judy> ...maybe the should are what the user agent can do

<Judy> ...if this is going to be a media platform, then we don't want the breakdown to be 'we can do text descriptions but we can't provide for audio description tracks"

<Judy> Janina: if you don't have a way to support how you implement something in the spec then you're nowhere

janina: i'm not clear that prioritizing these is the right way to go

<JF> Janina: if HTML5 is to become the platform for media, then we need to ensure that we have a means to capture all of these requirements, alternatives and requirements specified

john: don't disagree, but wonder whether we should start with author or 'must and should'
... think the latter because of what the engineers are saying
... think we should start with user agent requirements
... if our user reqs doc is more or less complete, i suggest our next discussion is ua requirements

<JF> Sean: next step is to turn user requirements to tech requirements

<JF> Eric: next step is to get clarification of some of the user requirements

<JF> Sean: agrees with Eric

shawn: next step is to turn these into tech reqs, then to decide what's on content and what's on ua

eric: think we first need to agree on the user reqs

john: so that should be our agenda for next week--item by item discussion and sign off
... any other business, questions for now?
... thanks to everyone!

- DRAFT -

HTML Accessibility Task Force Teleconference

02 Jun 2010

Attendees

Contents

requirements document review

Summary of Action Items

Scribe.perl diagnostic output