- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 14 Apr 2011 17:52:13 +0100
- To: public-html-a11y@w3.org
aloha!
minutes from the 14 april 2011 HTML Accessibility Task Force Weekly
teleconference are avialable as hypertext from:
http://www.w3.org/2011/04/14-html-a11y-minutes.html
as an IRC log from:
http://www.w3.org/2011/04/14-html-a11y-irc
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!
-------------------------------------------------------------------------
- DRAFT -
HTML Accessibility Task Force Teleconference
14 Apr 2011
Agenda
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0111.html
See also: IRC log - http://www.w3.org/2011/04/14-html-a11y-irc
Attendees
Present:
Eric_Carlson, Gregory_Rosmaita, John_Foliot, Judy, Michael_Cooper,
MikeSmith, Rich, Steve_Faulkner, janina, mranon
Regrets:
Laura_Carlson, Silvia_Pfieffer, Leonie_Watson
Chair:
Janina_Sajka
Scribe:
Gregory_Rosmaita
Contents
* 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
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List
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
content"
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
environment
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
HTML
... 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
Eastern
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
Canvas
<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-
html/2011Apr/0394.html
RS: didn't seem as if the chairs didn't really process all of my
comments
... detailed problems that chairs overlook in
http://lists.w3.org/Archives/Public/public-html/2011Apr/0394.html
... 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
has
... 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
magnification
... 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