W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

minutes: HTML Accessibility Task Force Weekly Telecon 2011-04-14 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 14 Apr 2011 17:52:13 +0100
To: public-html-a11y@w3.org
Message-Id: <20110414165113.M51345@hicom.net>

minutes from the 14 april 2011 HTML Accessibility Task Force Weekly 
teleconference are avialable as hypertext from:


as an IRC log from:


and as plain text following this announcement -- as usual, please
report any errors, omissions, mis-attributions, clarifications 
and the like by replying-to this announcement on-list...

please note that the following RESOLUTION was agreed-to at the
2011-04-14 HTML A11y TF telecon:

   RESOLUTION: first "text alternatives" subgroup meeting will 
   be held on Monday, 18 April 2011 at 11:30 am Boston time for 
   90 minutes under Judy's aegis

Further details about the inaugural text alternatives subgroup 
meeting on 2011-04-18 at 11:30 am Boston time will be circulated
to the public-html-a11y emailing list soon, so please monitor 
your list mail!



HTML Accessibility Task Force Teleconference

14 Apr 2011


See also: IRC log - http://www.w3.org/2011/04/14-html-a11y-irc


    Eric_Carlson, Gregory_Rosmaita, John_Foliot, Judy, Michael_Cooper, 
    MikeSmith, Rich, Steve_Faulkner, janina, mranon

    Laura_Carlson, Silvia_Pfieffer, Leonie_Watson



  * Topics
      1. Identify Scribe
      2.Text Descriptions Subteam Organization
      3.Text Alternatives Subgroup Timeline and Scope Discussion
      5. Canvas
  * Summary of Action Items


<trackbot> Date: 14 April 2011

<richardschwerdtfe> I am dialed in but here nobody

<janina> Meeting: HTML-A11Y telecon

<janina> Chair: Janina_Sajka

<janina> agenda: this

<scribe> scribe: Gregory_Rosmaita

<scribe> scribenick: oedipus

Identify Scribe


Text Descriptions Subteam Organization

JS: began discussion last week -- want to clarify what meant by text 
descriptions -- @summary, @longdesc, @poster, @alt, Figure/Figcaption, 
"discoverable metadata"
 ... subteam will make very specific recommendations on each topic
 ... aim is to not monopolize the TF call time -- been successful 
assigning areas of concern to TF for action

<Joshue> I am on another call at the moment but will track IRC.

JS: HTML5 going into last call -- need to ensure covers a11y as well 
as possible, and next steps
 ... appropriate name? time? scope?

JF: talking about "discoverable metadata" -- data or metadata about 
an element that is given to the user on request -- @longdesc poster 
child for this -- vaule of longdesc not given until user requests

GJR: goes for @describedby as well as @longdesc -- discoverable

JF: like term "discoverable metadata"

plus 1

JS: like to not do that for a particular reason -- no one opposes 
concept of discoverable metadata -- hard to see how is a11y issue 
per se
 ... make discoverable, end of story -- doesn't need to be identified 
only as an a11y issue -- concerned may be red herring to pull us off 
topic -- agree that is what we are talking about -- metadata and data 
that is universally discoverable

MC: name suggestions drawn from WCAG -- "text alternatives" (WCAG req) 
-- if more generic, "fallback content" (broader, but about 
alternatives), if broader, "programmatically determined accessible 

JB: ditto JS' concerns about "discoverable metadata" -- interested in 
MC's suggestions
 ... maybe just go with text alternates

GJR: not "fallback content" -- text equivalents, not fallback -- 
fallback for image is icon denoting image should be here

<JF> +1

<mranon> +1

<JF> +q

GJR: don't object to text alternatives

JF: @summary for TABLE -- no image, so no fallback -- need to keep 
as broad as possible
 ... subteam discussed last week was related to chairs' decision on 
@summary for TABLE -- this is "discoverable metadata" -- provided by 
author to aid those who need additional aid

<Joshue> +q to ask if Hixies latest outburst on how little he thinks 
of W3C process calls into question some of the decisions make 
regarding a11y?

<Joshue> -q

JF: push-and-pull -- if basic HTML pushed from client to renderers -- 
if need more info, can pull it using mechanisms provided (@summary 
@longdesc) fits larger model -- additinoal content provided by 
authors for a wide variety of users, not just screen reader users
 ... what is scope/goal of subteam?

JS: not to make discoverable, but to ensure that the necessary 
mechanisms needed exist

JB: suggested sub-group on small cluster of topics because: 1) pattern 
of rejection of a11y feature retention proposals; 2) HTML5 moving 
target needs to move along with a11y support intact as w3c document; 
3) lot of work, need unified stable proposals to take advantage of 
normal process for redress of a feature bing depreceated/removed 
without equal or superior mechanism
 ... last week question was on consensus on formal objection
 ... some thought might be futile, some thought not highest priority, 
some thought could be handled by expanding ARIA's scope
 ... perhaps there is an objection the group would want to present --
 ... expedited appeal -- wouldn't be convenient for chairs, may not be 
smothest way to go but not yet having that conversation
 ... subgroup setting could be helpful to make process options 
available and timeframes

<JF> +q

JB: reaffirm previous technical consensus or clarifying position to 
restore a11y support
 ... idea--move quickly, gather ideas, process constructively

JOC: Hixies latest outburst on how little he thinks of W3C process 
calls into question some of the decisions make regarding a11y?

JF: mentioned technical barriers/issues around reinstation of a11y 
features -- there are NO technical issues -- lack of support in GUI 

JB: don't believe there are technical barriers to a11y -- there are 
misconceptions though that need to be dispelled point-by-point
 ... fielded many complaints about chairs' decisions on a11y -- need 
to avail ourselves of process provided by chairs

JF: formal objection -- is goal to work towards very robust FO that 
addresses all of these issues?

JB: don't want to presupose groups' consensus
 ... did very quick poll last week -- TF divided -- would like to 
probe that
 ... wonder why not more FOs being generated from TF
 ... restore4a11y proposal by GJR could be useful form of objection 
to have on table -- have to look carefully at how process is expected 
to happen at FO stage to see if something useful there

GJR: change proposal, not FO

CS: couple of issues: 1) why no FO? discussions with HTML WG chairs, 
said FOs are for post-LC processing

JB: that's not the whole picture

CS: 2) decisions just came down in last couple of weeks --

<JF> +q

CS: 3) seems as if there is a whole category of things being rejected 
-- nexus "extra work for developers" and "hidden metadata" -- our 
approach is to push for native semantics, and to look at ARIA as 
extra work added on for devs/authors
 ... A11y API stuff or custom engineering best handled with 
cross-cutting technology such as ARIA
 ... devs already implementing HTML5 -- for some, can plug holes 
perhaps with ARIA

JB: hope CS signs up for subgroup

CS: as long as meetings don't start at 7am PT

Text Alternatives Subgroup Timeline and Scope Discussion

JB: LauraC volunteered via email
 ... timing issue with regard FO --
 ... timing distinction -- FOs not normally taken up until CR stage, 
but an important exception -- any FO can be appealed to director, can 
be appeal for expedited review -- can be considered nearly 
immediately --
 ... not convenient or welcome, but if need to address now, then need 
to address now
 ... surprised at what i am hearing

JS: not on table at time of @longdesc conversation

JB: hope to attend TF meetings regularly to keep up on strategy and 
getting native accessibility in addition to what is added via ARIA
 ... question of timing: deprecation, rather than removal, then take 
time to find how to do in truly corss-disability way
 ... can flesh out these questions in subgroup -- need to coalesce 
around responses that keep a11y in W3C's flagship publication

JF: personally, have problem saying: "here is aria stuff for people 
using AT" -- that is wrong and wrong-headed -- real reservations 
saying "catch the rest with ARIA"

SF: 1 point in regards what judy said about deprecate not remove -- 
that would involve reintroducing concept of deprecated

<Joshue> +1 to GJR, ARIA shouldn't be just about users of AT and then 
HTML 5 for everyone else, I think this kind of fork is an unfortunate 
by product of W3C process and HTML 5 politics.

JS: have "deprecated but conforming"

GJR: plus 1 to Joshue's IRC comments

SF: this terminology is not part of HTML5

CS: obsolete but conforming is a strange term but makes sense
 ... obsolete versus obsolete but conforming
 ... native semantics: there are diff ways to think about what native 
semantics mean -- i mean primarily things that are part of what devs 
are doing anyway -- name from text on button-- additional stuff devs 
have to add
 ... slightly diff way of drawing the line

RS: ARIA not a bridging technology -- things like standard widgets have 
to be made fully interoperable with AT without addding ARIA -- for 
things such as @summary @title -- ARIA meant to be cross-cutting tech 
to support AT -- way to apply a11y semantics for SVG and CANVAS and 
 ... canvas used to be separate from HTML
 ... there are advantages to having declarative API consistent across 
elements that can be controlled by AT -- not a bridging tech, but an 
a11y API feature that is declariative
 ... 80% less work to do same thing on desktop apps

JS: anyone can't live with name "text alternatives" for subteam to keep 
in sync with WCAG

JB: could approve general aim of subgroup, put out provisional title, 
figure out membership, and get started
 ... subgroup can figure out naming issue

JS: time for meeting?

JB: possible to have meeting at us eastern 11:30 am to 1 pm

JB: Laura will be able to participate to a larger degree at that time

JS: works for me

<Joshue> +q is there going to be a text @alt group?

<Joshue> -q

CS: not on regular basis

GJR: immediately follows ARIA caucus

RS: could do most of time

<JF> While not a great morning person, I can work with Monday 11:30 AM 

SF: could make part of it

GJR: can do entire meeting

JF: early, but can attend

JB: like this to be a provisional time and date -- Monday, April 18 at 
11:30 AM Boston time for 90 minutes

<Joshue> I can try also, depending on impending child.

MR: for me not good time -- perhaps can get colleague to join, but she 
isn't part of TF

JB: JS, MC and MS can talk to you about getting person plugged in

MR: thanks will follow up

MC: want to be involved but don't need another meeting

JB: is time ok?

MC: yes

JB: any other objections?

<JF> +1 to having Judy 's arm twisted <grin>

proposed RESOLUTION: first "text alternatives" subgroup meeting will 
be held on 18 April 2011 at 11:30 am Boston time for 90 minutes under 
Judy's aegis

proposed RESOLUTION: first "text alternatives" subgroup meeting will 
be held on Monday, 18 April 2011 at 11:30 am Boston time for 90 
minutes under Judy's aegis

JB: do intend to try to make sure process options are clear
 ... intend to ensure have good consensus-based discussion with clear 
understanding of all of the process issues

proposed RESOLUTION: first "text alternatives" subgroup meeting will 
be held on Monday, 18 April 2011 at 11:30 am Boston time for 90 
minutes under Judy's aegis

<JF> +1 to that resolution

RESOLUTION: first "text alternatives" subgroup meeting will be held 
on Monday, 18 April 2011 at 11:30 am Boston time for 90 minutes under 
Judy's aegis

RS: use what channel?

JB & JS: will announce the channel and other meeting info


<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-

RS: didn't seem as if the chairs didn't really process all of my 
 ... detailed problems that chairs overlook in 
 ... custom FocusRing can cause function to drop out -- author can 
manually draw focus ring, but that won't be a call to drive the focus 
ring after it ocurs
 ... highlighted in list of bugs
 ... x,y coordinate provided with intention to drive magnifier as caret 
moves, but currently tied to focus ring drawing -- functions don't 
match -- chairs reviewed -- we provided info on how to drive magnifier
 ... why shouldn't author be able to override focus ring setting user 
 ... details provided in cited email
 ... not considered: we met with magnifier devs to solve the problems 
for magnification -- chairs didn't recognize this
 ... put proposal in -- if continues to be a problem will probably do 
formal objection -- want to give chairs chance to re-examine data
 ... hixie asked what to do - my response is don't do anything -- 
completely broken as-is

JS: decision takes out ability to support magnifiers -- you are asking 
them to reconsider?

RS: chairs' decision was leave function as is, which breaks 
 ... increases burden on author and still breaks magnification
 ... on windows, doing direct draw -- need function to capture graphics 
calls to display blinking cursor
 ... bug need to address: baseline for test metrics -- multiple 
baselines in canvas spec == have to specify which baseline

JS: task force might want to be signatory of Richs' FO

GJR: sees a pattern of rejection

JB: RS clarification useful
 ... point is to get all info into 1 FO

JS: volunteer to scribe next week?
 ... i and marco won't be on call next week, MikeSmith will chair next 
week's TF meeting

Summary of Action Items

 [End of minutes]

Received on Thursday, 14 April 2011 16:52:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC