HTML Accessibility Task Force Teleconference -- 10 Dec 2009

<trackbot> Date: 10 December 2009

<LeifHS> I will be following the meeting via IRC. Will that count as participation? Or as regret?

Previous: http://www.w3.org/2009/12/03-pf-minutes.html

<scribe> scribe: Gregory_Rosmaita

<scribe> scribenick: oedipus

Previous: http://www.w3.org/2009/12/03-pf-minutes.html

Opening Thoughts and Organization

MS: JS, MC, and i have brainstormed on TF priorities
... agreed that conformance criteria for ARIA attributes should be one of our top priorities
... discuss during call, follow up with email discussioni
... performance criteria for ARIA in HTML5
... propose changes to spec, get agreement in TF, align with TF's assesment about what to do
... 2 documents to work from

<MikeSmith> http://dev.w3.org/html5/spec/embedded-content-0.html#annotations-for-assistive-technology-products-aria

MS: first use of ARIA in HTML5
... states what conformance criteria for ARIA should be

<MikeSmith> http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html

<cyns> related document: http://www.w3.org/WAI/PF/aria-implementation/

MS: second is SteveFaulkner's comparison

<cyns> discussess mappings from aria to platform APIs

MS: saw http://spreadsheets.google.com/pub?key=toQHOF3-IiYACgHX9bs2GrA&single=true&gid=0&output=html but not directly related to HTML5

CS: is related to HTML5 - have to ensure compatibility and coordinate drafts

<Stevef> http://spreadsheets.google.com/pub?key=toQHOF3-IiYACgHX9bs2GrA&single=true&gid=0&output=html

MS: particular issue of HTML use of ARIA - only change can effect in HTML WG
... how ARIA integrated into other MLs out of scope for this TF

SF: first document doesn't actually help much at all; that's why i created the google spreadsheet at http://spreadsheets.google.com/pub?key=toQHOF3-IiYACgHX9bs2GrA&single=true&gid=0&output=html
... Cyns and i have been working on it since prior to TPAC 2009
... contains much more useful notes and suggestions and thoughts and change proposals; not complete, but more annotated and easier to follow; incorporate input from TPAC break-out session

MS: spreadsheet superseeds documents i cited?

SF: as per HTML5, yes

MS: compare spreadsheet to spec
... spreadsheet not been formally agreed upon by TF

CS: did have consensus of those at TPAC for "override" mechanism with ability of specific ARIA roles can and should trump HTML5 native semantics
... makes sense to override link role="widget" -
... trying to work through mash-up issues
... thought we had consensus that this was right approach

<Hixie> i don't think it really makes sense to override a link with role=button, personally

SF: amongst people at TPAC 2009, yeah

<Hixie> but i could see that other ones would make sense

<Hixie> (e.g. the ones in html5 already)

<paulc> ok

<Hixie> MikeSmith, it's the first thing in the table of the aria section

<richardschwerdtfe> scribe: Rich

<richardschwerdtfe> Cynhthia: Not all widgets can override all other widgets

<richardschwerdtfe> Cynthia: we provided groupings

<richardschwerdtfe> Cynthia: there are some native roles and aria roles that are compatible and can override and we needed to find out when

<richardschwerdtfe> Cynthia: that had concensus at TPAC

<richardschwerdtfe> Cynthia: anyone else who was there?

<richardschwerdtfe> scribe oeddipus

<richardschwerdtfe> scribe: oeddipus

<oeddie> MS: currently have 2 tables - 1 lists elements that have strong native semantics, and implied ARIA semantics - don't see that all from first table only have role listed there and cannot be overrwritten

<oeddie> MS: second table, can be overridden

<oeddie> MS: second says what role should be

<oeddie> MS: don't have agreement among people involved in discussion that hixie is correct

<oeddie> MS: A element - role currently limited to "link"

<oeddie> MS: discussed cases where people use role="button" in wild onto A

<oeddie> MS: need specific case resolutions - have to go through spec and point out specifically where need / want changes to it

<oeddie> MS: changes to 2 tables or addition to 2 tables

<oeddie> CS: what is in the spreadsheet is everything in 2 tables - what overrides what ARIA roles makes sense

<oeddie> SF: best way forward to put in change request for each line or row of table?

<oeddie> MS: no

<oeddie> MS: that would be overkill

<oeddie> MS: don't have huge amount of disagreement

<Hixie> seems reasonable

<oeddie> MS: probably could bring this back to being specific request - open as issue in bugzilla, list changes, point to URI with change proposal, hixie can then review and comment upon it and then discuss with hixie - can happen on A11y TF list

<Hixie> you want to make an <address> into a widget? o_O

<Hixie> personally i wouldn't be able to study them in detail enough to respond on a call, and would much rather have more time to study them

<kliehm> @hixie +1

<richardschwerdtfe> +1

<richardschwerdtfe> scribe: Rich

<Stevef> hixie: i don't but if people do then its preferable that the widget is identified

<Hixie> seems better that if people do they stop doing it :-)

<richardschwerdtfe> Mike: since we have a spreadsheet it would be best to go through the spreadsheet.

<richardschwerdtfe> Steve: I think that people generally agree about the approach

<richardschwerdtfe> Steve: the majority of the possible changes could be contentious

<richardschwerdtfe> Steve: I would like to have some take on the widget controls

<richardschwerdtfe> Steve: some people override them to look like the would in a supporting browser

<richardschwerdtfe> Steve: currently in the spec. it says you can't do this.

<richardschwerdtfe> Cynthia: The right thing may be for one of us to write the general approach in a note.

<richardschwerdtfe> Mike: exactly, that is one action we should assign as a result of the call

<Stevef> hixie: yes but they won't, if you can persuade them please do

<Hixie> personally i think the general approach i've heard described seems reasonable, but i get the feeling many of the details are less obviously right, fwiw

<Hixie> Stevef, why can you convince them to use aria but not to use <div> instead of <address>?

<richardschwerdtfe> ACTION: Cynthia write overall approach HTML support of ARIA [recorded in http://www.w3.org/2009/12/10-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-1 - Write overall approach HTML support of ARIA [on Cynthia Shelly - due 2009-12-17].

<richardschwerdtfe> Mike: so that is step number one and that will help

<richardschwerdtfe> Mike: I still think it is useful for it to be documented for the conformance criteria

<richardschwerdtfe> Mike: We will have remaining some specific instances in which we have disagreement as to what the specification should say

<richardschwerdtfe> Mike: people agreed with the general approach (<a>) but not that specific case

<richardschwerdtfe> Mike: not a complete change proposal but a list of what should be affected in the change to the current HTML 5 specification

<richardschwerdtfe> Mike: it is not clear from the spreadsheet as to what changes should be made to the specification.

<richardschwerdtfe> Cynthia: so there are two efforts: finish the change proposal and outline spec. ready changes

<richardschwerdtfe> Cynthia: this could be another column in the speadsheet.

<richardschwerdtfe> Mike: yeah

<richardschwerdtfe> Cynthia: the other thing would be to create the two tables

<Hixie> deltas are what matter in terms of reviewing the changes, imho

<richardschwerdtfe> Cynthia: we need to figure out the best way to institute the changes

<Zakim> MikeSmith, you wanted to say to Hixie that I can't see that the current HTML5 spec text actually prohibits a/@role=button and to

<richardschwerdtfe> Gregory: Stuffing so much information into tables is not the best solution for low vison users. Especially due to scrolling

<richardschwerdtfe> Cynthia: to gregory: let's figure out a way to present the information

<Stevef> hixie: as this is hypothetical its difficult to argue why one could be convinced, of one or the other

<Hixie> Seems like people who care about accessibility enough to use aria would also care enough to do the right thing in the first place

<Hixie> which isn't to say they wouldn't use ARIA

<Hixie> but ARIA would make more sense with <div>s than with just the wrong HTML element in the first place

<richardschwerdtfe> Mike: what I would like to propose is that someone on the call today perform an action item that describes in prose what needs to be made to the specification.

<Stevef> Hixie: it may well not about caring it may well be about a business decision

<Hixie> i don't see how a business decision would say anything about using <address> or <div>

<richardschwerdtfe> Mike: we need consensus by the task force that reflects consensus

<richardschwerdtfe> Cynthia: So, you want the discussion to be a change proposal vs. a spreadsheet change

<Hixie> i don't think we need a whole change proposal initially -- just a list of what the requested changes are, and why

<Hixie> so that people can review the proposed changes

<Hixie> (for me the spreadsheet is fine)

<Hixie> (it just needs to be a bit less ambiguous about what is being proposed)

<richardschwerdtfe> Mike: we need to spread out the responsibilities

<Stevef> no but a business decision may be do the least needed adding an attribute could be easier than changing an element

<richardschwerdtfe> Mike: it is a just a few sentences to describe where the changes need to be made

<Hixie> Stevef: that line of argumentation suggests we shouldn't have any sort of conformance criteria, just allow everything

<richardschwerdtfe> Mike: to gregory how long to do this?

<richardschwerdtfe> Gregory: week to 2 weeks

<richardschwerdtfe> Rich: I think end of January - this gives people time to review the spreadsheet, send in comments, and submit them in. Tag them with ARIA.

<richardschwerdtfe> Michael: I will put this in an email message. but have people submit comments with ARIA in the subject line

<richardschwerdtfe> Michael: in the mean time you can get started on the change document

<richardschwerdtfe> ACTION: Gregory Deliver draft of change proposal for ARIA additions to HTML 5 by 12/24/p9 [recorded in http://www.w3.org/2009/12/10-html-a11y-minutes.html#action02]

<trackbot> Created ACTION-2 - Deliver draft of change proposal for ARIA additions to HTML 5 by 12/24/p9 [on Gregory Rosmaita - due 2009-12-17].

<Stevef> hixie: if developers are allowed without conformance constraints to add javascript based interaction to any element that effectively turns the element into a widget, then either the conformance constarints need to be tightened up for this or developers need to be able to add ||ARIA to explain these interactions to AT users

<Hixie> Stevef: agreed. so we shouldn't allow that. and html5 doesn't (it says you must use the appropriate element and must use elements according to their meaning).

<richardschwerdtfe> Rich:

<richardschwerdtfe> Rich: yes

<richardschwerdtfe> Michael: that is all we need to do on the call today

<Stevef> hixie: yes, but it is meaningless as there is no check for it

<richardschwerdtfe> Michael: We need to follow up with a status report on the other subgroups

<richardschwerdtfe> Michael: we don't have new information from the media video task force

<Hixie> Stevef: it's hard to check for that, but there is one check -- if they use aria in a way that conflicts the element's meaning, we can detect that and then we know there's a problem, and we should report it ("wrong element, for buttons use <button>" for example)

<Stevef> hixie:but aria use here is not the problem and aria should not be used as a flag, taking the aria away would make the element less understandable and usable for the AT user

<richardschwerdtfe> Rich: Investigating use of media querries to be used to select alternative content for canvas. there is general agreement to use a backing dom with aria support to support canvas accessibility

<Hixie> stevef: we should never have a validator say that hte author should take the aria away, i agree. The spec is clear about that (it's one of the few UI requirements, in fact)

<richardschwerdtfe> Rich: to set up a meeting for canvas

<Hixie> Stevef: that doesn't mean we can't use it as a flag though

<richardschwerdtfe> MikeSmith: any other issues?

<richardschwerdtfe> MikeSmith: video caption and canvas are the other two big accessibility items

<richardschwerdtfe> MikeSmith: the summary discussions are continuing

<richardschwerdtfe> Gregory: we can put developing bugs into bugzilla

<Stevef> Hixie: so would you predcit that using ARIA as a flag will lead developers using more appropaite elements or removing the aria?

<richardschwerdtfe> Gregory: the command element does not provide a descriptor and I plan to log a bug if that is accepted by the task force

<Hixie> Stevef: if the error message tells them to use a better element, i think that's what they'd do

<MikeSmith> http://www.w3.org/WAI/PF/HTML/wiki/Main_Page#Bug_Collection_.26_Development

<richardschwerdtfe> MikeSmith: Does the group have anything to do with this

<richardschwerdtfe> Rich: are you saying the command the description of the element

<Stevef> hixie: i have less optimism for that outcome

<Hixie> re <command>, feel free to file a bug and i'll look at it

<richardschwerdtfe> Gregory: it supports title but that that has problems.

<richardschwerdtfe> Gregory: there is ambiguity

<richardschwerdtfe> MikeSmith: We need to discuss this but not on the task force mailing list just now

<richardschwerdtfe> MikeSmith: place on bugzilla and discuss in HTML community list. If your issue is not addressed then bring back here

<richardschwerdtfe> MikeSmith: Any other business?

<richardschwerdtfe> MikeSmith: We are going to have the call next week at the same time. Anyone want to scribe next week?

<richardschwerdtfe> SteveF: I will scribe next week

<richardschwerdtfe> Janina: I will chair next week

<richardschwerdtfe> MikeSmith: we are done for today.

<richardschwerdtfe> RSSAgent, draft minutes

- DRAFT -

HTML Accessibility Task Force Teleconference

10 Dec 2009

Attendees

Contents

Opening Thoughts and Organization

Summary of Action Items

Scribe.perl diagnostic output