HTML Accessibility Task Force Teleconference -- 20 Sep 2012

<trackbot> Date: 20 September 2012

<janina> Meeting: HTML-A11Y Task Force Teleconference

<scribe> scribe: MichaelC

Getting HTML5 to Recommendation in 2014 http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html

js: Proposal from HTML chairs

also signed off by me, Judy, Philippe

goal to get HTML5 to Rec in 2014

it's only a proposal right now

we should discuss

but not expect to come to conclusions

plan could change based on discussion here, in HTML WG, and in PFWG

<Judy> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html

<Judy> http://www.w3.org/QA/2012/09/getting_html5_to_recommendatio.html

<Judy> http://lists.w3.org/Archives/Public/public-html/2012Sep/0243.html

<Judy> http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

jb: first link is announcement of plan from Paul

second is blog by Philippe

third is another announcement of plan

fourth is the plan proposal itself

Philippe and I signed off as Domain leads, Philippe's role wasn't specific as W3C management representatives, but rather he and I are counterpart domain leads; we are also both part of W3C management.

there's a lot of detail including re accessibility

have seem some good requests for clarification on the lists

would like to have a HTML co-chair go over plan

and then Janina or I may go into accessibility implications in more detail

<rubys> one error: http://lists.w3.org/Archives/Public/public-html/2012Sep/0269.html

plh: we have found one error at least

so we know the plan will change

sr: nothing to add to PLH

not sure going through plan point by point will help, though can

jb: some high level points

one is emphasis on modularity

<paulc> joining soon

features could start as extensions, and either move to standalone spec with separate timeline, or get integrated into core spec

one aspect of background context is the existing different conformance model for HTML5 spec, more of a smorgasbord of what implementers may choose

so extension specs could be considered peer-level specifications with the core

the plan also gives a mandate to this task force to work on extension specs

seeking careful review and consideration of whether this would work into the future

js: there's been some question about how TF decisions are weighed in HTML decision process

this plan shifts authority to TF to develop specs for features of key interest

sf: if an extension spec provides a feature not in HTML5, it seems to work

if an extension changes or removes an HTML5 feature, it gets messy

<rubys> Background on Steve's point: http://lists.w3.org/Archives/Public/public-html/2012Sep/0282.html

I tried today creating an extension spec to remove <hgroup> and ended up needing to copy the whole spec with references removed

<rubys> Background on Steve's second point: http://lists.w3.org/Archives/Public/public-html/2012Sep/0284.html

also was caught by surprise by recommendation to move text alternative document to the TF

since I'm the editor

jb: one part of the plan is "willful violations"

which extension specs can do

think the general intent was not to remove existing accessibility support

but to provide a smoother path to development of features that hadn't yet made it in

including different timeline

there is still effort to remove text alternative section in spec

sr: wouldn't want an extension spec to be an entire replacement of spec

would prefer to come up with a core spec that can be cleanly extended

should work together on how to do that

sf: keeping <hgroup> would be controversial and potential accessibility impact

would prefer to see a "clean" core spec and all these features as extension specs

sr: what do you think should become of the text alternative doc?

sf: prefer to leave it where it is

if it's an extension spec making a willful violation of HTML, it's less strong

js: what if the conflict with what's in HTML now gets resolved?

sf: then we could re-assess

right now everything in flux

js: seems to me Steve's concern with <hgroup> is similar to others' concern about separating ARIA integration into an extension spec

process-wise, nothing's fait accompli, so now is opportunity to ask about the fate of the text alternatives doc

pc: text alternatives document has a Formal Objection against it that it can't be normative because it contradicts HTML5

doing it as an extension spec flattens that problem

sf: it already presents itself as an extension

jb: one question I've heard in background is implication on forking

hearing that this plan more clearly provides a way to address the FO on the text alternative doc

<Stevef> paulc: "This specification is an extension to the HTML5 specification [HTML5]. All normative content in the HTML5 specification, unless specifically overridden by this specification, is intended to be the basis for this specification." http://dev.w3.org/html5/alt-techniques/

but also have heard that if various extensions taken at different times, the accessibility features could fragment

not sure if it's a problem, but have had questions from some places on that

how do we keep extensions from becoming fragments?

pc: speaking as Microsoft representative - we don't look at where a feature is documented, core or extension

i.e., RDFa vs microdata, chose to implement both

should address perception that where something is documented might affect implementation

implementers implement features that the market demands etc.

<rubys> +1 to "we can't resolve everything today"

js: note we can't resolve everything today, so we're just discussing issues

<paulc> Implementers choose features to implement that are a) well specified and b) meet market demand

jf: concerns about optics

e.g., FO that text alt document contradicts HTML

<paulc> In my view implementers don't worry about "where" something is specified ie in a core spec or an extensions spec

<rubys> formal objection that jf and others have referenced: http://lists.w3.org/Archives/Public/www-archive/2011May/0051.html

suggest we could lead to a "HTML+A11Y" variant

which marginalizes accessibility

in this particular example, there are conflicting viewpoints about how to handle text alternatives to best meet the needs of the customer

pc: hear this as a concern about the "end game", is that accurate?

jf: partly

I hear there will be willful violations

what will ordinary implementers make of this?

which version will they choose

the FO puts weight on a direction

pc: I'm concerned about the end game

want to get past Last Call and find path to end game that makes everyone happy

we've been discussing issues with alt and suggestions to address

note recent change of editors

and work with the new team by opening bugs etc.

the situation of "opposing sides casting missiles at each other" doesn't work

I agree with some of the concerns

the plan gets us to CR, takes some of the pressure and tension off

and gives opportunity to merge things back in later

jb: potential for marginalization of accessibility one of the greatest risks we saw going into this plan

importance of having solutions available for HTML 5

makes it worth proceeding along this route

depends on a lot of things working well

there have been questions about reintegration path

procedure is documented in the plan, and there are conditions

the features must meet the CR exit criteria

<rubys> exit criteria: http://lists.w3.org/Archives/Public/public-html/2012Sep/0215.html

note the "Public Permissive CR Exit Criteria" is what's meant by that

look at that, and how it might apply to extension specs, particularly ones hoped for reintegration

the other criteria is whether the extension spec can gain consensus of the HTML WG

that may mean developing clearer explanations, or developing the features in a way that may receive broader acceptance

jf: going back to optics

<rubys> feel an important point judy made might have been missed: proposals may need clarifications or may need adjustment to gain wider consensus

I'm trying to keep an open mind

but prospect of HTML+A11Y variant is a non-starter for me

not just for impact on implementations

but also on authors

many of whom have particular requirements

forces them to make a choice between forks

how do we avoid the perception of two standards (whether it's real or not)?

pc: did moving RDFa to a separate spec constitute a fork?

in that case there was even a competitive spec, microdata

but there's huge adoption of both

understand the perception issue, but don't think the reality need lead there

have many similar examples where forking feature out didn't inhibit adoption

jb: don't want to downplay concern about optics

have seen that over my years in developing accessibility solutions and observing what gets implemented

there could be a tendency to grab core HTML 5 and ignore extensions

looking at that from a marketing perspective

for the plan, want to see if it's sufficiently addressed in what's here

in some adoption contexts, could be very important to promote as a set

there are good things in the plan to try to address all this

welcome input to strengthen that

js: underlying concern isn't technological

it's "to ghetto or not to ghetto"

not just accessibility, is a common sociological concern for marginalized communities

today, some of the historically severe marginalization of people with disabilities is hard to understand but it's part of our context

note the proposal cuts both ways

do recognize need to balance optics

<Zakim> rubys, you wanted to say getting in the spec doesn't cause features to be adopted; as paul stated, what causes features to be adopted in a clear specification that addresses a

sr: reiterate that getting feature in spec doesn't get it adopted, JF even on record saying that

jf: accessibility isn't a feature, it's a core requirement

referring to it as a feature misses the bigger picture

going back to RDFa vs microformats analogy

it's known as "HTML+RDFa"

so there's an optics problem there

<paulc> Are people aware that the AC has approved a new charter for the RDFa WG that gives them responsibility for the HTML+RDFa specification. It is being moved out of the HTML WG.

the willful violation is core of my concern

sf: RDFa vs microdata - there were negative attitudes about microdata that persisted; and RDFa was easily moved out

<paulc> While I don't disagree with Steve's point, the main reason why Microdata was moved out was to put it on the same footing as RDFa.

understand implementers will implement what they will, but concern about what's in or out of the spec affects validator behaviour and perception of developers

regardless of what is in fact implemented

js: Willful violations was definitely a concern

jb: there was discussion of feature vs core requirements

may want to promote a family of HTML 5 specs

understanding reintegration path impact on accessibility will be valuable

perhaps we should talk about timelines etc.

pc: chairs will eventually do a call for consensus

but have no schedule, because weren't sure what response would be

don't want to prematurely close discussion and call for consensus

but do request input as soon as possible

<rubys> pointer to validator discussion: http://lists.w3.org/Archives/Public/public-html/2012Sep/0283.html

note for HTML+RDFa, that spec is being moved out of HTML to RDFa WG

so extension specs don't even have to be done in the HTML WG

to point out a positive of extension specs, they can be modified without modifying the core spec

if ARIA were an extension spec, e.g., adding aria-describedat might be easier

sr: as soon as extensions make it to FPWD, they would be implemented in the validator

js: strong point

<Zakim> JF, you wanted to note that we have already noted that there are 2 type of "conformance" - implementation and authoring

jf: there are already two conformance criteria

I do support modularization of development

<rubys> s/<missed>/once an extension spec gets to FPWD, I expect that it will be quickly added to the W3C validator/

just don't want accessibility to seem like an optional add-on

may be just optics

js: could be opportunity for strength

jf: ... have to talk more about that ...

js: thanks all, let's join the HTML WG meeting

- DRAFT -

HTML Accessibility Task Force Teleconference

20 Sep 2012

Attendees

Contents

Getting HTML5 to Recommendation in 2014 http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html

Summary of Action Items

Scribe.perl diagnostic output