HTML Accessibility Task Force Teleconference -- 07 Apr 2011

<trackbot> Date: 07 April 2011

Agenda Review

<inserted> scribenick: Stevef

MS: not too much agenda one is talk about 1st public working draft for API ammping doc

JS: wants to talk about @summary

JB: maybe talk about @poster decision

<oedipus> plus 1 to poster

MS: any other suggestions?
... hearing none

video poster issue 142

<oedipus> HTML Working Group Decision on ISSUE-32 table-summary: http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html

MS: lets not cover hgroup today
... put mit on agendum for now and will be on for next week

Canvas Subteam Report

MS: canvas subteam, only a few people on the call right?

RS: only a few on the call, usuallu only a few
... waiting on chairs decision on issue 133, thinks we are in good shpe, depends on chahirs, other issue how do we get bounding rectangles on objects so that magnifiers can identify

<oedipus> clickable regions on use of clickableregions to feed bounding examples: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0090.html

RS: not retained graphics in canvas, required for solid hit testing vehicle to drive AT support

<oedipus> http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll/results

RS: example shows that to get around this developers use multiple canvas objects ugly

<oedipus> minutes of canvas call 2011-04-04 http://www.w3.org/2011/04/04-html-a11y-minutes.html

RS: svg is having drawing path, canvas needs one to, have sent ian use cases, waiting to hear back, once we have hittesting will be able to drive accessibility

MS: canvas is not retained mode by design, feature not shortcoming

<oedipus> ever heard of unforseen consequences

MS: essentially this can be seen as canvas being made into something it was nevr intended for, any response?

<oedipus> a11y is often the "canary in the coal mine" when it comes to "standard" architectures

RS: understand apples intenet for canvas, but reality entirely different, unlike svg most people doing desktop apps usnderstand canvas, they wiil/are using canvas to cerate applications, so from a11y perspective at the end of the day still have to have access to it, for a11y need fetaures built in

<oedipus> profiles was feedback from the TV industry at TPAC 2010 HTML WG F2F

RS: at last tpac set top manufacturers said sweet spot for html5 will be canvas + JS
... whats happeneing is not what was intended need to take this into account

MS: this is not an incremental; change its fundemental change to architecture of canvas implementaion, is it necessary and why?
... what will they gain?

RS: do we have to do a full blown reatined mode? I don't think we do, only needed for hot testing

MS: probably said enough for now, have enough info to go forward

JF: canvas + JS thanks

RS: ian highlighted need to develope solution not just for accessibility, hiti testing does that
... not askin g for all, just enough to support a11y

<oedipus> hit-testing is needed by AT devs -- they asked for it

RS: put in a very simple hit testing stratgey on top of canvas without having to have full retained mode

MS: bug triage next, mike, marco, martin?

Bug Triage Report

MC: not much done,in last few weeks

<oedipus> plus 1 to big thanks to bug triage team

MS: letting things queue up a bit due to last call
... bug triage team greta job!
... no urgency

OK thanks

media subteam report

<oedipus> media telecon minutes from 2011-04-06 http://www.w3.org/2011/04/06-html-a11y-minutes.html

JF: focused on vexing issue 152, multitrack API, chairs granted extension, have 3-4 solid proposals with fundemantal differences, still talking issues through
... lot of discussion about Ian's mediacontroller proposal, discussion about master timeline, still dissecting options, will be having to con calls a week for the next few weeks, convey our sense of urgency to chairs please mike
... resolution critical to last call
... general feeling is that calls are productive

MS: you sid it would be extremely problematic if we get it reoslved prior to last call,

JF: if we can't do it we cannot provide sign language captions

MS: does not mean we won't vere have it but not just before last call

JF: if it goes into last call without then the htnl5 spec will not be complete

<Zakim> judy, you wanted to further clarify for Mike

MS: HTML WG or W3C process does not require it to be complete before going to last call

<oedipus> http://www.w3.org/2005/10/Process-20051014/

JB: people feel that significant requirement will niot be met if certain requirements are not in the spec, multitrack is something that is needed to meet the crieria of being feature complete before last call
... if there was progress before last call, the co-chairs asserted that they would not stand on formality, thats why people are working hjard to get consensus before last call

<MikeSmith> I don't accept the assertion that not having this decided by start of LC will compromise progress of implementations during the coming year

JB: one of the reasons why the last call timimg is of concern, is as we all know it is being implemented as it involves, not having stable multitrack will comprimise implementations in the coming year, thinks track it is one now is making gopod progress so should not be an issue

<Zakim> MikeSmith, you wanted to say that this is not a "must" requirement in the process document, and the WG chairs have discretion to determine LC process for their groups

<JF> +q

<oedipus> http://www.w3.org/2005/10/Process-20051014/tr.html#Reports

<oedipus> http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance

<oedipus> this is similar to canvas -- it is being implemented NOW by fiat without a11y isxues addressed, and it is MUCH harder to address a11y after-the-fact than building it in from the start

MS: prcess doc does not say the spec has to be feature complete, gives WG chairs discretion, which is what the HTML chairs are doing, also do not agree that it will comprimise implementation in the coming year regardless ofif this gets decided before LC
... if we try to force resolution before lC could be a problem, we have people working together, on the path to resolution

JF: moving to alst call will we continue to get heartbeat udpates during last call? after may 22nd

<oedipus> http://www.w3.org/2005/10/Process-20051014/tr.html#maturity-levels

MS: its up to html wg chairs for publication, they feel strongly about heartbeat requirements, feel they will be pushing to continue . also implementors will work from editors draft not stable spec
... what authors of books and turorials do we can't have control over

JF: so impelemntors have control?

<Zakim> oedipus, you wanted to say that 1 problem is blind obedience to "WG process" -- canvas a11y work was a specific task of Canvas Subteam, there should have been no call for

MS: yes implementors have control over wehat goes into the spec

Gregory: disagree with process

MS: need to take it up with the chairs
... talke it up on the html call/mailing list

<JF> You can have Quality, On budget, and On Time - pick 2

<JF> +1 to Judy

MS: affects us but we cannot do anything about it in the a11 task force

<oedipus> plus 1 to judy -- W3C process different from "WG process" set up by chairs, but they are following cookie-cutter process which is detrimental to development of spec

JB: it may be useful to refer to 2 different levels of process 1. w3c process protective of accessibility , html wg microprocess directs them to issue call for proposal even on areas that have been worked on by taskforces

<oedipus> http://www.w3.org/2005/10/Process-20051014/tr.html#maturity-levels

JB: we have disagreements amongst w3c reps in regards to feature completeness. disagree on interpretation of feature completeness
... have several items in a11y area now where it may need a forma objection. one of the process things that is very clear if you disagree there are steps to object

would,like to get groups disagreement documented

<eric_carlson> minus 1 to Judy -- giving *any* group of experts absolute authority is a bad idea

<JF> @ eric_carlson - as opposed to allowing uninformed participants steam-roller issues that harms real accessibility?

JB: my sense is moving things that are stuck, may be usefulto get a more focused discussion, form subgroup to develop propsoal aroun alt issues

<oedipus> eric_carlson, we aren't asking for absolute authority -- only that the HTML WG and chairs recognize that accessibility is the specific focus of the TF and the WAI and that info from those fora deserve to be listened to and not told that our use cases concern someone's mother-in-law (see last week's statement by paulc)

JB: media current status, support from co-chairs, not stand on ceremony if progress to consensus

ARIA Mappijng Report

<oedipus> MS: summary of where subgroup is at?

<oedipus> SF: haven't had meetings due to other work and due to work assigned at SD f2f

<JF> +q

<oedipus> SF: 2 areas of work: 1 writing text for definition of @role and aria attributes in HTML5 -- will ocur during last call

<oedipus> SF: 2. HTML-A11y-API doc -- emailing those concerned to get more fomal process to work on document -- a lot of work -- need others' involvement

<oedipus> SF: HTML-A11y API mapping document will get more attention once the aria-in-html work is done

<oedipus> CS: should see progress in 2 weeks time

<oedipus> MS: announced on list consensus for FPWD of A11y APIs

<oedipus> MS: waing for chairs to send request for transition to plh

MS: paul said we had consensus for html accessibility API guide to be publsihed as FPWD

<oedipus> MS: waiting for comm team to get frist FPWD published -- maybe tuesday or thursday this week

oedipus: can you scribe now as i gotta go soon/

@summary for TABLE

<oedipus> HTML Working Group Decision on ISSUE-32 table-summary: http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html

<inserted> scribenick: oedipus

JB: assume everyone on call has read WG decision

[general yeses]

JB: yes or no question: do people feel that HTML5 is feature complete without @summary for TABLE

SF: yes

GJR: no

JS: no

JF: no

CS: can live with it (actgually, without it in HTML5)

RS: my take on @sumjmary -- advantages to saying can do same things with ARIA that is cross-platform
... some advantages to control what we provide in host langauges -- have to do if summary out or not

<JF> +q

JB: do people feel co-chairs decision on table summary showed full understanding of the accessibility issues and accessiblity in general

<Stevef> SF:yes

GJR: no definitely not

JF: hixie posted to mailing list that ARIA only for A11y API mapping
... hixie claims aria only affects a11y API mappings and only for ATs

RS: design is interoperability for AT

JF: quotes from hixie
... decision for TABLE summary is wrong because says use ARIA to fix all problems
... goes in wrong direction

RS: alt is also used when turn graphics off -- alt text would be rendered in content, so has additional functionality
... doesn't apply to @summary
... could do same thing through A11y API
... some ATs will use DOM -- get same static info

JF: looks like trying to use conformance checkers to undue existing attributes in HTML4/XHTML1
... what is practical impact of removing @summary for TABLE from HTML5?

RS: if comes out, need to provide WCAG 2.0 techs to deliver what summary does today -- how to do with ARIA
... don't worry about conformance checkers -- most content today is all rendered on client and conformance checker would miss that -- A11y test tools test dynamic content -- can tell if @summary or aria-label missing
... validators today miss most of today's web content

JB: may need a subteam to look at mulitple issues concerning alternate descriptions of content -- several appear to be lacking -- rejected or lack of understanding of rationale by chairs

<MikeSmith> before we adjourn, is there anybody please who can volunteer to scribe for next week's call?

JB: on @longdesc concerned that TF role a bit confused -- subgroup could stablize and champion propsal

JS: have action to write up use cases to write up -- should take LC's proposal to TF and work on it from there

<Zakim> oedipus, you wanted to say @summary cannot be "pushed-off" onto ARIA -- what about thosee who don't use AT

<judy> JB asks who's interested in sub-group on alternative descriptions? perhaps people can start expressing interest in irc now?

<JF> Judy - add me

<JF> +1 to greg

the chairs have removed a feature of HTML added EXPRESSLY to increase accessibility--this should NOT have been done without acknowledging the need/use cases clearly articulated from those who directly benefit from @summary--can we perhaps have a PF/WAI finding that all markup introduced to HTML4 expressly for accessibility MUST either be equaled or improved by HTML5, which means not judging...

scribe: such markup by "standard" web metrics;

Scribe for Nest Week's Call

JB: best to rotate --

judy, micheal has a scribe rotation list

MS: anything else need to do before adjournment?

<MikeSmith> adjourned

<richardschwerdtfe> Judy: sure I would be happy to participate in subteams on some of the issues such as text equivalents

- DRAFT -

HTML Accessibility Task Force Teleconference

07 Apr 2011

Attendees

Contents

Agenda Review

Canvas Subteam Report

Bug Triage Report

media subteam report

ARIA Mappijng Report

@summary for TABLE

Scribe for Nest Week's Call

Summary of Action Items

Scribe.perl diagnostic output