HTML Accessibility Task Force Teleconference -- 20 Jan 2011

<trackbot> Date: 20 January 2011

<paulc> Trying to join on Zakim, but my machine has been asleep for 3 weeks and it is taking some time to get going today!

<paulc> No sympathy requested or expected.

<MikeSmith> http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

Face to Face

<inserted> scribenick: oedipus

RS: mike are you coming?

MS: travelling to cambridge to meet with administration/management -- may stay in U.S. for couple of weeks
... probably need to figure out travel and plan on attending

JS: hoping that PaulC could attend

MS: would be in San Diego

PC: in Ottowa
... been gone for 3 weeks - -have to catch up -- exact dates?

JS: 19 and 20 March 2011 (Saturday/Sunday)

PC: week aftger SXSW

JS: yes, venue and date due to CSUN conferenfce

<MikeSmith> scribenick: oedipus

PC: will get back to JS and MS on attendance -- would seriously like to attend -- may be going to SXSW -- have to coordinate

<MikeSmith> Confirmed Face to Face meeting of HTML Accessibility Task Force

MS: MCooper posted details to list confirming times and dates and location
... anything new MCooper?

MC: meeting page without full info yet

<MichaelC> Face to Face meeting page

MC: assumption is will be in meeting room of Hyatt in San Diego -- not confirmed -- up to host
... create registration survey and post to public-html-a11y

Survey on Text Alternatives

<MikeSmith> results of survey on text alternatives

<scribe> scribenick: Stevef

whats going to be done with the survey?

<inserted> scribenick: oedipus

SF: didn't go into detail in comments, but could....

MS: purpose of survey collect data responses on consensus within group about various exceptions -- exceptions for cases where 1 can omit @alt

<inserted> scribenick: Stevef

survey closed, purpose to collect data and responses on text alternatives do we have consensus on exceptions

<inserted> scribenick: oedipus

MS: want to decide which exceptions we support, and which we don't

SF: need more reasoning?

MS: need more respondents -- but is that necessary?

<inserted> scribenick: Stevef

not worth providing more reasoning

<oedipus> MS: how to procede?

JS: survey do we have support for a particular proposal

<oedipus> GJR: propose that we give TF members another week to fill out survey

JS: on alt text in HTML5, look at survey and compare to chart of lauras

MC: not opposed but not for extending survey

<oedipus> GJR: if summarize results and post to public-html-a11y can give TF members a chance to evaluate and endorse

MS: muliple change proposals will proceed through wroking group anyway, should taskforce endorse one or more

JS: mike is right
... a range of probabilities, where is the consensus?

JF: seem to be clear trends in survey

JS: if we have consnensus maybe we don't need more numbers
... lets take the trended responses and refere to chnage proposals

<oedipus> plus 1

<richardschwerdtfe> BRB

<oedipus> http://www.w3.org/2002/09/wbs/44061/201101-issue-31/results

<inserted> scribenick: oedipus

SF: in agreement with trends -- 1 for aria-labelledby conforming text alternative and role="presentation" -- disagree with these because neither fulfill same role as @alt in browsers, no indication UAs will treat the 2 in the same way, and there is open hostility to using ARIA-annotations to "fix" normal display in UAs
... for aria-labelledby, how would serve as text equivalent?
... empty @alt with role="presentation"
... graphical browsers, when image loading turned off, needs a non-ARIA solution -- what is missing is some plan or proposal for how UAs will implement this

CS: underspecced aria-labelledby and role="presentation" for "regular user agents"

SF: looked into aria-labelledby quite a bit in composing Alt Text Techs -- have not found aria-labelledby sufficient to replace @alt -- may be useful in case where one uses FIGURe and FIGCAPTION/CAPTION but haven't found good use cases for it

RS: use labelledby when have text that is visible -- if embedded text, use aria-label

SF: understand use cases -- what i haven't found is evidence for use of aria-labelledby without an @alt without an image on a web page

RS: if have @alt, use it

SF: true

RS: if have large chart and have the title for chart then there is your labelledby value, but separate from chart

CS: use cases for no @alt
... suggestion is not require aria-labelleby, but that it is ok to use

<JF> +q

SF: can't come up with reason to use aria-labelleby that is superior to using @alt

RS: big picture with short name (CAPTION for sighted users)

SF: that is what FIGCAPTION is for
... if caption element, make relationship programmatic between image and caption
... issue with describedby and labelledby -- if have text elsewhere on page, when get to imagtte, hear referenced text -- still hear text when read-all --

<eric> should we be concerned that a group of the world's accessibility experts can't agree on how to label an image?

SF: aria-labelledby scenario -- in application mode -- not getting access to on-screen text -- moving between focusable elements

GJR: role isn't defined in HTML5 spec
... need to pin down what a @role in HTML5 is

RS: aria-integration -- role refers to section of ARIA where role attribute defined

<inserted> scribenick: SteveF

RS: had to update the sectionin the aria spec to define role

<JF> +q

<oedipus> RS: have to define @role

GJR: HTML5 spec does not define @role, and ARIA states that @role is similar to that defined in Role Attribute, but no normative reference to @role from HTML5

JF: if alt is not present then others will suffice

<inserted> scribenick: oedipus

SF: if have a piece of text that is referenced by aria-labelledby, that text becomes accessible name value for image -- no semantic distincition

JF: always said that @alt should never be supplied by machine -- same rule for labelledby -- can't be assigned programmatically or by authoring tool

SF: that ends up doing the same thing as @alt does
... got a heirarchy of things

GJR: we want a cascascade of equivalency

SF: when issue of providing reason for aria-labelledby use i came up with Flickr to re-use heading or title on page for image (if one image on page or one image in DIV) -- TITLE best for aria-labelledby
... different from authoring practices -- limitation of tool
... auto-generated web page, should create a relationship automatically

MS: what actions can we take away to move this forward?
... not saying don't need progress on these issues, but unsure of where to go from here -- could say disagree with some deatails of change proposals -- first task: find out what TF feels about change proposals
... change proposals will move forward if submitted by individuals
... what is the TF role in this?

JS: did survey results highlight agreement?
... Laura charted what supported -- need comparison

<inserted> scribenick: Stevef

JS: somebody needs to compare change proposals

<inserted> scribenick: oedipus

JS: extend survey -- not going to hold anything up

<inserted> scribenick: oedipus

<inserted> scribenick: Stevef

JS: lets extend the discussion

MS: you and i can talk about this lets extend survey for another week
... TOPIC: Media Sub-Team Report
... media subteam any bdiscussion about feedback from google?

JS: not discussed but make way to talk about it next week
... talked about poster issue, various points of disagreement, we uncovered another requirement whcichis not documented yet
... no programmatic way to tell browser i don't want autoplay

<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2011Jan/0152.html Google feedback on HTML5 media a11y (Silvia Pfieffer)

MS: sounds like a big deal, next step? do we need to file a bug/

JF: yes absolutley

JS: can you file the bug?

JF: yes

MS: move on it sooner ratrher than later

eric: not sure if its a user agent problem or not

MS: google feedback is good should act on it pronto, nit delay

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings/Minutes#Canvas_Accessibility_Teleconferences:_2011

Canvas Sub-Team Report

rich: close on focus ring, still working on caret, google may join the meetings

<oedipus> the EXPERTS (AISquared) said they need caret even without RTE

<inserted> scribenick: oedipus

RS: use contenteditable?

SF: using the DOM

RS: if use DOM and not using canvas, still have to deal with grammar and spelling errors -- problems that don't go away -- plus NEED a caret
... same set of problems with RTE or other interactive CANVAS implementations
... caret helps with positioning of text -- populated to a11y API layer -- only thing left is grammar and spell-checking
... use case: VM access to a Unix system -- wrote modification to canvas that intercepts drawing calls that would create virtual desktop via CANVAS so can work on own machine remotely using CANVAS
... once 1 has canvas, 1 opens a HUGE bucket of worms

MS: should investigate in more detail

ARIA Mapping Sub-Team Report

SF: ARIA mapping call
... hixie provided an alternative counter proposal -- some things quite useful -- pointed out errors and issues with alt spec text -- started to work way through to pull out items that need further discussion
... won't make major difference if don't include the changes that have been suggested for spec text -- worth discussing the bits to get down to core issues
... me, Rich, DBolter, Cyns will attend next week
... put hixie's counter proposal in wiki
... now counter propasal has been submitted, have time to respond -- can we modify our proposal to reflect new information?

[TWO MINUTE WARNING]

PC: if can't get consensus on initial change proposal and do call for counter-proposal and info in counter-proposal contains info that means original change proposal needs tweaking -- best thing to do if impact original change proposal, tell chairs that and negotiate a schedule before chairs run survey
... make clear to WG and counter-proposal author how trying to take their comments in consideration by chaning change proposal
... short answer: yes

SF: hixie posted bug on this -- claimed won't be implemented
... HTML to A11y API mapping hixie claims not needed; browser vendors disagreed, now hixie posted bug against whole thing to reflect his change of mind, but no details on ISSUE-129 -- when wilil he elaborate on his thinking?
... need to know what hixie intends to put into spec before can comment

MS: understood

PC: should make clear from your position what you believe is blocking next step -- write email to make clear to chairs that don't want to proceede to survey until all info available and all parties have time to reflect on issue
... also, ask me questions when i am here (and i try to make all the meetings i can)

SF: reasonable questions asked yield no response -- what to do other than wait?
... deafining silence in some areas

PC: if feel that is happening, please send me a private note -- going to drop off for HTML WG call

Bug-Triage Sub-Team Update

MS: bug-triage update?

MC: dealing with bugs, want to mark verified and close, but not original filer, so in limbo -- want to know how much discretion is up to triage team

JF: who filed bugs?

MC: various people

JF: contributor@whatwg.org bugs been mostly closed

MS: for those, once triage team reviews, TF has to take ownership so that action can be taken on them
... if no one complains, then ok -- if complaints, then deal with them as specific problems

<richardschwerdtfe> sorry, had to drop

MK: we can verify without problem -- Laura wanted to know once a bug is verified/fixed original reporter has 2 week time frame to close or reply -- if no reply, closes automatically after 2 weeks

MC: process feature?

MS: yes

MC: a lot of bugs are still open

MK: ok to verify bug -- next person who comes across it can close it

MC: didn't have that understanding

MS: think in decision policy document

MC: says bug closes, but not who closes it

MS: should raise as decision policy bug -- will look into this today and talk to chairs about this

<kliehm> Once a bug is verified the reporter has two weeks to respond, otherwise the bug can be closed.

Timeline to Last Call

GJR: change proposals due 22 january 2011 to be considered pre-Last Call comments

January 22, 2011 is the cut-off for escalating bugs for pre-LC consideration--all issues in tracker, calls for proposal issued by this date. Consequences of missing this date: any further escalations will be treated as a Last Call comment (http://www.w3.org/html/wg/wiki/LastCallTimeline)

s/a+//G

[ADJOURN]

- DRAFT -

HTML Accessibility Task Force Teleconference

20 Jan 2011

Attendees

Contents

Face to Face

Survey on Text Alternatives

Canvas Sub-Team Report

ARIA Mapping Sub-Team Report

Bug-Triage Sub-Team Update

Timeline to Last Call

Summary of Action Items

Scribe.perl diagnostic output