WAI Coordination Group -- 19 Jan 2011

<Judy> chair: Judy

<scribe> scribe: jeanne

Report on HCG Audio Discussion http://www.w3.org/2011/01/14-hcg-minutes.html

Janina: The meeting was about gathering requirements. Several of groups had similar requirements.
... there seems to be agreement, even though no one was speaking for real time communications. The audio devices on users systems regardless of the OS involved.

Judy: This is different from the media format working group we have been envisioning?

Janina: this is different. This is more about processing audio and audio transformations - for example, filtering out certain frequencies
... there will be a followup conversation, hopefully soon.
... the media subteam has not wanted to wait for another group to spec out the controls. It would take longer, but I am concerned that the media group may do it too fast. We need a solution that is more generally applicable.

JB: So is this an already chartered group that is developing requirements? I am trying to figure where it is in the process.

Janina: There is a draft charter, but the requirements were beyond the scope of the charter.

<Judy> presumably this: http://www.w3.org/2010/12/audio-wg-charter.html

Janina: I want to have a spec that will address browser based player for audio.

Jeanne: Does this belong in UAAG?

Janina: The generalized cases belong in UAAG. The HCG is defining an api for transformations of sound.

Judy: So the requirements belong in UAAG, and the API development belongs in audio.

Janina: I am promoting HCG because there is a generalized need for it that goes beyond accessibility

Jeanne: The requirements from the HTML/media task force have been reviewed by UAWG. Most of the requirements are covered by UAAG, and UAAG took action items to add some items, but not all.

<Judy> look at: http://www.w3.org/2010/12/audio-wg-charter.html#scope

jeanne: UAAG needs some technical expertise on these issues, could HCG provide this?

janina: It could be difficult because each platform OS is different.

Judy: this is a good time to comment on the charter because it will probably be addressed by W3M next week.
... You will need to have a liaison between the groups.

jeanne: Mark Hakkinen has been very active in UAAG on these issues.

Judy: Scope is ok, Deliverables add the audio device API, and add UAAG to the dependencies.

ack

<Zakim> jeanne, you wanted to ask about inclusion in UAAG

<scribe> ACTION: Jeanne to follow up with Mark Hakkinen about liaison with HCG [recorded in http://www.w3.org/2011/01/19-cg-minutes.html#action01]

<trackbot> Created ACTION-76 - Follow up with Mark Hakkinen about liaison with HCG [on Jeanne Spellman - due 2011-01-26].

Realtime Communications WG -- Who can we send?

janina: We need someone who is expert in deaf and HH to work with this group. We could talk to Judy Harkins, who just retired.

Judy: See if she can recommend someone, we can provide interpreters as needed.

Janina: If Galladet would take this on, this new person would be ideal.
... I'm not sure what the REal TIme Working Group timeline is.

Rethinking ARIA's Value

Janina: The reason we have ARIA is to expand many technologies, not just HTML5.
... this may be a useful bridge technologies, rather than a patch while we wait for HTML5. ARIA gives us a way to do this in many languages and we have not promoted them enough.

Michael: Janina and I were discussing and realized we had different perspectives, and that had implications for HTML5 and other languages.
... ARIA was originally conceived as a patch, but the other alternative is to see ARIA as an accessibility language, and encourage other languages to support ARIA and encourage its use.
... I would prefer to encourage native semantics and use ARIA as a bridge technologies. I made a pro/con list which is not complete.

<MichaelC> Baking ARIA

janina: this came out of @longdesc discussion. If we are only going to need it in HTML5, then it belongs there, but if we need it in other languages, then we should put it in ARIA.

<Loretta> Michael, can you paste in the url again?

Jan: there are no easy answers. The pro's seem to have a slight edge.

<MichaelC> Baking ARIA

Judy: ARIA has ended up with a protocol that is probably higher than we expected. There are robust support materials coming together.
... ARIA may not be the ideal vehicle for the packaging of accessibility information, but it has so much prominence that it could be a good springboard.

Janina: ARIA is 80/20. It doesn't solve every problem, but having a consistent case for everyone to follow is valuable.
... so are we going to need it in HTML5 or should we put it in ARIA.next

Michael: user interface semantics are in a different layer than host language semantics. ARIA works in SVG. Cons: it requires @@. Accessibility gets limited to ARIA, and new technology may be delayed for updates to ARIA.

Janina: the 80% frees up developers to work on the 20% where ARIA doesn't work.

Jan: there are so many other technologies. How does ARIA apply to SMIL and SVG?

Loretta: what are we trying to decide?

Janina: whether @longdesc should be in ARIA or HTML5
... we have most of it covered in ARIA except for the mechanism for going off-page - @aria-described-at

Michael: My concern is ghetto-izing accessibility. That new host languages will not be built including accessibility.
... I see it getting worse over the past few years.

Judy: The HTML5 group has not been a conducive envirnment for collaboration. Many other groups, but not all are better for a collaborative discussion and problem-solving.
... If we weren't to use ARIA, what would be the mechanism to have accessibility in these host languages.

Michael: WCAG. If we were saying the host language were providing it, it could chose to use it's own element to meet the need without the @aria- attribute, but it would map to ARIA.

Jan: Would we then ask HTML5 to remove @alt to be consistent.

Janina: maybe in the next version.
... the messaging should be that ARIA takes care of most of it, and we should work together to solve the issues that ARIA doesn't.

Judy: I think it would require a fair amount of on going promotion to make sure that ARIA didn't fade into the background, unless we were to agitate for obligatory conformance.
... then it would not be a ghetto-ized solution, and becomes a solution that has a path for technical expertise.
... Define the way we want ARIA to unfold, to insure that the next version of ARIA has what you want in it, and then to talk with colleagues in other groups to be incorporated by reference into other specs. That could be a win-win, where the accessibility solution is defined by the people with the most expertise, and incorporated into other specs in a consistent way.
... it would also be less vulnerable to the ripping apart uses of time and energy, like we have seen in HTML5.

Michael: I am concerned about average web developers, thinking about @aria- is not needed unless they are working on accessibility.

Judy: we can continue to use @alt to stand for the simplest accessibility feature, but it turns out to be one of the complex issues.

Michael: When we talk about incorporating ARIA, we could start by removing the "aria-" label, and having people harmonize it. That would address the ghetto issue.

Judy: would you be able to do it in CR?

Michael: No, it would not be backward compatible, and developers put a lot of work into the aria- labels.

<Loretta> ok

<Jan> I can

Jan: The ghetto argument assumes that ARIA for accessibility and developers won't do it, but we have to get developers to think about ARIA for information architecture.

Janina: Like " this is an electronic curbcut, you don't need a wheeelchair to use it"

<Loretta> We ned to find another client to take advantage of the ARIA attributes.

Michael: Next step is to post the pros/cons of this discussion, but I think we have moved beyond it. I think we are looking at a baked in ARIA approach and the considerations of implementing it.

Judy: What about drafting a straw position on this leaning in that direction that we could look at more closely and respond to at our next meeting.

<scribe> ACTION: Janina to draft a straw-man proposal on the position of ARIA [recorded in http://www.w3.org/2011/01/19-cg-minutes.html#action02]

<trackbot> Created ACTION-77 - Draft a straw-man proposal on the position of ARIA [on Janina Sajka - due 2011-01-26].

<scribe> ACTION: Michael to draft a straw-man proposal on the position of ARIA. [recorded in http://www.w3.org/2011/01/19-cg-minutes.html#action03]

<trackbot> Created ACTION-78 - Draft a straw-man proposal on the position of ARIA. [on Michael Cooper - due 2011-01-26].

janina: I will ask Rich if he has run into use cases of non-accessibility uses of ARIA.

Jan: Like a bot using ARIA for testing.

Preparing W3C/WAI comments on US DOJ ANPRM on Web Accessibility

Judy: The ANPRM recommends adopting WCAG @@lost@@
... the timing trick is that the DOJ comments are due on Monday. I am working on a draft by tomorrow.
... there are other approaches circulating. There are other organizations submitting approaches that are supportive of WCAG harmonization.

<Judy> three relevant links:

<Judy> http://www.justice.gov/opa/pr/2010/July/10-crt-850.html

<Judy> http://www.ada.gov/anprm2010/factsht_web_anrpm_2010.htm

<Judy> http://www.ada.gov/anprm2010/web%20anprm_2010.htm

Judy: We will be promoting harmonization

publications check-in

Loretta: WCAG is looking to publish Silverlight and PDF techniques. In Feb depending on "Michael-cycles"

Judy: Did the process of publishing a working draft get the results you wanted?

Loretta: We got good comments.
... I think it had a 6 week comment period, but it was over the summer.

Jeanne: We did get a commitment from Microsoft that they would complete their patent policy review by 19 January. IF they meet that, UAAG will be ready to publish.

Judy: make sure Shawn knows about it.
... A proposal was submitted to the EU last week. We brought in partners in Europe with skills that were appropriate to the paths we were defining.
... the bulk of the work and resources would be centered in WAI in Europe. It covered funding of a accessibility supported technology repository, and web resources, and support for work in the Research and Development group area.
... only one proposal will be chosen, so keep your fingers crossed.

update on EC Proposal submitted by WAI through W3C/ERCIM yesterday

Next meeting

Next meeting 2 February

<Jan> sorry no

<Jan> sorry no time

- DRAFT -

WAI Coordination Group

19 Jan 2011

Attendees

Contents