- 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