HTML Accessibility Task Force Teleconference

18 Feb 2010


See also: IRC log


+1.609.482.aaaa, Ben_Caldwell, Cooper, Cynthia_Shelly, Gregory_Rosmaita, Janina, Janina_Sajka, John_Foliot, Jon_Gunderson, Markku_Hakkinen, Matt, MikeSmith, Rich, Steve_Faulkner, Stevef, Wendy_Chisholm, chaals, dsinger_, paulc
Denis_Boudreau, Eric_Carlson, Marco_Ranon, Bruce_Lawson, Kelly_Ford, Laura_Carlson, Martin_Kliehm, Joshue_O_Connor


<trackbot> Date: 18 February 2010

<MikeSmith> Stevef: http://dev.w3.org/html5/alt-techniques/

<Stevef> mikesmith:thanks

<MikeSmith> Stevef, I'll set up the bugzilla component now

<Stevef> cool

<scribe> scribe: Ben

Action Item Review

<MichaelC> action-2 due 4 March

<trackbot> ACTION-2 Deliver draft of change proposal for ARIA additions to HTML 5 by 2009-12-24 due date now 4 March

<wendy> ??P9 is wendy

<MichaelC> action-8 due 4 March

<trackbot> ACTION-8 Follow up with IE team about whether implementers are willing to use parent/child/nesting relationships could be used in mappings logic due date now 4 March

Canvas Report

RS: We've figured out a way to use content in the subtree for dual purpose. We've got agreement from some browser vendors.

<dsinger__> S/apple/an apple engineer/

<paulc> who is ??P9

<oedipus> wendy

RS: Think we've adequately explained the issue and can move forward.
... SF Action to add an API for canvas, but canvas API has been separated out from HTML5 spec.
... Authors can always provide different UI features to render content differently. Working with Dave Singer on media queries related to whether to turn captioning on or not. We've used access for all vocabulary to do the spec, which allows us to address education level, hazards, ... configurability of UI, etc. if the author wishes to support these features.
... Would have the ability to selectively render different types of content based on user prefs.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas

RS: Trying to get this to a point where it's consumable for the rest of W3C for review.

Media Subgroup Report

<JF> http://www.w3c.org/2010/02/17-html-a11y-minutes.html

we had a call focusing on markup of captions, subtitling, etc.

converns about complexity for authors, looking at roles and selection of different media properties

JF: A lot of work happening right now

JS: Significant discussion on list, please contribute.

Summary Change Proposal


JS: We have a change proposal on the table plus a draft related to how details will work

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010

CS: Two competing absolutes in our discussion of summary. One is around having a way to have data that is only avail. to users who can't see (that is usually hidden from those who can see). Situation that people who work in accessibility run into where they don't want to add something because of impact on design.

<oedipus> hidden versus discoverable content is how we should approach the issue

CS: Second one says that anything an author can't see, they are likely to mess up.
... There's another one about text strings within attributes being problematic, but not as much discussion or concern around this one.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010#Internationalization_.28i18n.29_Considerations

CS: Goal to find something everyone can live with. Proposal does deprecate summary (obsolete but conforming). Would probably result in a warning that suggests you do something else instead.
... Current spec doesn't include an alternative. Proposal is to add details element to table. Would, from a programmatic standpoint, do the same thing as summary.
... By default, details would be visible (show/hide that users could open to display the information within it.)
... Advantage is that there is a clear migration from summary to details.

<oedipus> why must details be visible by default -- it should be up to user configuration -- if i can see the table and process it, i don't need to review the details; if i cannot process the table, i need the details, but i suppose having it visible by default allows for interactivity

CS: Visible piece of UI in details currently is an element called summary, but it is really a toggle button. Proposal changes this from summary to button and to have a default rendering with a small graphical button. Idea would be to have an actual button that acts like an actual button.

GR: Why must details be visible by default? Shouldn't that be a user configuration option?

<dsinger__> Surely the style sheet can control visibility?

CS: Expect screen reader to render it by default.

<oedipus> dsinger, want a native HTML solution, not push-off to stylesheets

CS: Making it visible by default serves as reminder to authors that it there. What's described in proposal text is what a visual UA would do with it.

DS: Can you style it?

CS: Yes, should be able to, but not addressed specifically in proposal.
... would rather have a single attribute than to style with CSS and script

<Zakim> oedipus, you wanted to say shouldn't we push for a native HTML solution, not a push-off to stylesheets

<oedipus> my hand has been up

GR: I feel more comfortable with a native HTML solution, not a push-off to stylesheets. If not an HTML solution, just saying use CSS is really not going to cut it.

<oedipus> GJR says if CSS is solution, then isn't CSS solution to tabular data display?

<oedipus> can't have it both ways...

<oedipus> if CSS is solution, then deprecate TABLE for all uses in preference to stylesheets

CS: Another concerns related to semantics of button (as purely a form field), need to think about that some more.
... Another question has to do with whether behaviour is presentational or not

JS: Seems that we are very close to approving a recc. on summary. Not sure we're 100% there, still button issue, CSS vs. attribute issue, but we are very close. Are people generally happy with this proposal?

<oedipus> GJR likes DETAILS idea - if CSS is solution, then CSS should be used to control layout of tabular data, and TABLE should be deprecated for ALL uses

CS: There are some concerns. There is a proposal to remove the details element.

<oedipus> http://www.w3.org/html/wg/tracker/issues/93

<paulc> Suggest Cynthia should table her reasons for wanting <details>

<oedipus> http://dev.w3.org/html5/status/issue-status.html#ISSUE-093

<oedipus> URIs for shelly powers' proposal and comments

JF: if it is a button, appropriate to push presentation to stylesheets

<paulc> Shelley suggest: This type of functionality is trivial with JS.

<paulc> If there is disagreement then people should push back on that thesis.

<oedipus> the devil is in the <DETAILS>

JS: Seems that we're pretty close to agreement on this. Are there people who would not vote for this proposal?

<chaals> [I can live with it]

<oedipus> i can live with it with caveats

<paulc> Should the TF do an email Call for Consensus?

<dsinger__> Vote is a strong word but this should clearly be pursued

<oedipus> janina, paul is on the queue

<paulc> What does "vote this out next week" mean?

JS: Not hearing any disagreement. Thanks to Cynthia. Let's talk again next week and discuss with HTML WG participants as possible.

<oedipus> thanks cyns, for taking the bull by the horns (pun intended?)

JS: Will do a survey on this.

PC: Wanted clarification by what is meant by "vote next week." A little more clear that survey is the right way to go. What are triggering events that start that and when exactly do you think it's going to happen?

JS: Triggering events are resolution on remaining issues, by next week, I mean about the time of this call next week.

MC: Propose that triggering event is that someone sends a final proposal that covers reamining issues and ping me on creating survey.

<oedipus> please consult discussion page for details proposal from 2010-02-15: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010

RS: Should canvas proposal go through survey as well?

JS: Yes.

Details Draft


WC: Let's try to provide consistent ways for AT to pull the info. they need. One issue that exists currently (HTML 4) is that there is an inconsistency between browsers related to parsing rowspan and colspan. I've been focusing on table algorithm to be sure we get consistent info from tables when we query for headings etc.
... One aspect of this is to add a shadow column element to get groups of columns. AT is designing their own mechansims for getting this information. Proposal to provide some consistency to include methods to add/remove columns and address spreadsheet like functionality.
... Trying to figure out why this hasn't existed in the past. Closest is colgroup, but not quite right. Still a lot of work to do, looking for feedback about whether this is headed in the right direction.

<oedipus> GJR thinks wendy is on right track

<oedipus> wendy, don't forget: "A conclusion is simply the place where someone got tired of thinking." (Arthur Bloc)

WC: Why this hasn't been done before? Would something like this get tracktion in HTML WG? Hoping to talk with Raman further.

<dsinger__> S/tracktion/traction/

<scribe> ACTION: Charles to dig up history on column element [recorded in http://www.w3.org/2010/02/18-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-20 - Dig up history on column element [on Charles McCathieNevile - due 2010-02-25].


WC: Any feedback would be helpful. If we can have a richer API, I think AT would use it. One challenge is that AT has to do different things in different browsers to get table information. For WebAnywhere, have to recreate it myself.

JF: There was some work in HTML WG where they looked at table algorithm. Early assertions were that algorithms exist to extract summary info.

<Stevef> table inspector HTML5 http://james.html5.org/tables/table_inspector.html

<Stevef> me/ chaals: any more on opera canvas image map support?

WC: Will continue work on this, may be a couple weeks before ready for review again.

<wendy> stevef--thanks. the table inspector looks interesting.

JS: Important that the HTML WG knows that this is coming.
... Encouraged that we're really rolling now. Thanks to all.

Summary of Action Items

[NEW] ACTION: Charles to dig up history on column element [recorded in http://www.w3.org/2010/02/18-html-a11y-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/02/18 17:04:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Ben
Inferring ScribeNick: Ben
Default Present: John_Foliot, Gregory_Rosmaita, Cooper, Janina, Stevef, Matt, Ben_Caldwell, Cynthia_Shelly, Jon_Gunderson, Wendy_Chisholm, Rich, +1.609.482.aaaa, Janina_Sajka, dsinger_, Markku_Hakkinen, paulc, Steve_Faulkner, chaals, MikeSmith
Present: +1.609.482.aaaa Ben_Caldwell Cooper Cynthia_Shelly Gregory_Rosmaita Janina Janina_Sajka John_Foliot Jon_Gunderson Markku_Hakkinen Matt MikeSmith Rich Steve_Faulkner Stevef Wendy_Chisholm chaals dsinger_ paulc
Regrets: Denis_Boudreau Eric_Carlson Marco_Ranon Bruce_Lawson Kelly_Ford Laura_Carlson Martin_Kliehm Joshue_O_Connor
Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0363.html
Found Date: 18 Feb 2010
Guessing minutes URL: http://www.w3.org/2010/02/18-html-a11y-minutes.html
People with action items: charles

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]