See also: IRC log
<oedipus> new wiki pages:
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Meetings/Minutes/Caucus (historical)
janina: 2 action items, cyns posted her item, so mark as closed
... aria conversation has not moved to email, need to get agenda moving
... touch base with sub teams - canvas
Rich: asked for canvas neet today, need shadow dom to support accessibility, also need to support alternate interfaces, based on commenst from j craig and dave singer
<Zakim> oedipus, you wanted to ask rich if want to try and get RWAB XG successor group to develop the shadow DOM as a RIA
rich: problem is media quieries don't exist so need to add to CSS, how do we co-ordinate this, but do believe that it is needed, shadow dom is not enough, call at 3pm boston time
janin: can people announce themselves
dsinger: what is needed new keywords for CSS media queiries?, or syntax and processing rules/
rich: need to support more than the media types in html5 today
dsinger: there will be new media queries
rich: examples needed: high contrast, keyword
dsinger: CSS working groupo supportive of this
rich: may need user agent to do best fit, requested alternate
... main issues, shadow dom and alternates
GJR: suggested shadow DOM as a RIA
<chaals> [regrets for the meeting today :( ]
<oedipus> SteveF: as far as shadow DOM and activedescendent as main way to control?
rich: yes we are going to want shadow RIA
<oedipus> tabindex versus SVG-suggested "order" attribute for Access Element
janina: main intereste in subteam reports are co-ordination issues
rich: who in CSS to talk to?
disnger: put it up on the wiki, CSS mailing list of meetings
rich: there is a post out on the canvas mailing list , please repsond dsinger;
disnger: video subtema report: some stuff up on wiki
janina: main topic: summary attribute, contraversial, people continue to discuss, no reoslution, PF has asked for it to be put back, but still discussion goes on
cynbs: long thread on mailing list based on chnage proposal,
<oedipus> Current State of @summary discussion (CynS) - http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0094.html
cyns: new stuff suggsted to be put into summary
<oedipus> we are facing an endemic fear of invisible meta-data and meta-data in general
one of the main objection it is hidden, so will probably be incorrect or out of date
cyns: hidden meta data is bad, details has hidden data by default
<oedipus> s/hidden meta-data is bad/contention is that hidden meta-data is bad/
cyns: validation warning on @summary is a blocker for accessibility people
... people have been asking for data, talking past each other as what means data is not agreed
cyns: did a a quick review of summary data, found that what was available was often useful
<levy-aurelien> meta data is hidden most of the time, the problem is reable hidden meta data
cyns: leif hs made an alternative proposal, seemed inter suggested media type setting top display hidden mataesting, but don't have time to pursue, also display of summary (when?) maybe in authoring scenarios, maciej in particular didn't like it
janina: whether data is hidden or not is not an accessibility issue
<levy-aurelien> it is for cognitive accessibility
janina: if other users want to use the data, then they should tell the users agent to display
cyns: hidden or display is of summary is an issue for authors and designers
<oedipus> there is (a) a need for the TABLE's structure and organization to be communicated to those who are parsing the TABLE non-visually, or through a VERY small point-of-regard and (b) no reason why a user agent, an authoring tool, or any other program cannot provide a means to expose the content of @summary at a user's request -- whatever form that request takes, but there is NO usability need to provide ALL users with a summary which is intended to provide co
cyns: if summary users toogleable with a default of hidden
chaals: stuff that the author or user doesn't look at gets broken quicker than stuff that the author/user does see
chaals: this thinking then leads to statements of summary being bad for accessinbility, i don't agree with this, what harm is done by content that is wrong?
<Zakim> chaals, you wanted to say things that go wrong aren't always harmful, and arguing forever on something that existed is harmful
<cyns> http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0056.html near the bottom of this post, there is a list of summaries from a web crawl that the original analysis thought poor, but that I think are useful
<wendy> I'm happy to help.
chaals: all out of band description stuff suffers from this issue, one of the design principals missing is does this do damage/, but if this group were to say, having accessibility attributes that may contain wrong content does nopt necessarily cause harm.
i am losing sound can someone scribe until i can hear again
<wendy> cynthia: I'm happy to work with you on any of the summary stuff.
<richardschwerdtfe> scribe: Rich
<richardschwerdtfe> cynthia: Wendy, I will take you up on that
<oedipus> scribenick: richardschwerdtfe
janina: you need someone on the cell API?
wendy: I can work on both
cynthia: data analysis. we need to look at this on the call. I sent a link earlier.
cynthia: I need advice (this call for data). I went through examples of bad summary and more than half were helpful. I would like someone to weigh in on whether my assessments were useful.
<Stevef> rich: i am back
matt: Hixie's statements that some were harmful were incorrect in my mind.
<Stevef> cyns: haven't seen people going bthrough and checking crawls
cynthia: I have not seen people that went through the calls that said whether the summaries were useful
... for example calendar, search results, main content, mp3 downloads, ... many of these were useful as summaries
<Stevef> I have
cynthia: has anyone spent time going through these?
matt: my recollection of the long list was that 20 percent were bogus. Some use meta data that was just garbage. One bad tool should not account for 20% of the content that was out there. ... the numbers start to turn around
<Stevef> also many 'bogus' summarys are never heard by AT users as they are on layout ttables that are ignored by AT
matt: it easy to pick out things that do what they were intended to do.
cynthia: I did not go through the whole thing. The most common summary was calendar
cytnthia: i did not do a percentage but half were useful which is different from the impression that others gave.
janina; 50 percent is very good
cynthia: they did identify the table pretty well
... banner, etc. was a good chunking mechanism. I need someone from the HTML working group that can help me surface this.
steve: if that information is in the hidden meta data that is good.
cynthia; saying that something is a calendar is not useful to a sighted user
<wendy> calendar may not be necessary, it is certainly not "harmful."
<dsinger> but is it harmful to re-inforce the truth?
janina: the hiddenness is not the accessibility feature.
<Stevef> summary attribute usage data http://www.paciellogroup.com/blog/misc/summary.html
<dsinger> perhaps we should therefore make it 'gently visible' by default (because then people will notice things that are wrong)...
<oedipus> dsinger, that is an authoring tool's responsibility
cynthia: I am leaning on keeping summary and details - which are both hidden. Place text in the text to visualize captions where necessary. The author should provide a user controllable switch for showing these. The browser could provide this functionality. We should further expose the table API to AT.
<oedipus> 15 minute warning
<chaals> [I thnk the validator warnings are one of the big barriers to consensus]
<oedipus> dsinger, CAPTION for TABLE is terse descriptor, @summary for table is long descriptor
cynthia: Am I correct in the disability community is that the concern is the validator warnings.
janina: yes, as it tells the author they can't do this
... we now place ourselves in conflict with U.S. govmt., for example, where summary is entrenched.
<LeifHS> <summary>: Many authors, such as in government, like to know when they have fulfilled their duty. Today this is "easy": Did you use @summary? Yes or no? If there were a corresponding visible <summary> element (as child of <caption>, I see no other option), then the question could be: Did you use either @summary or <summary>. In my view it is also needed to separate the "clean" caption information from the explanation information that HTML 5 now allows inside <c
janina: we perhaps could engineer a better summary
... we need to move through a phase of re-engineering
... the wording is not good
Steve: I wanted to say in reference to what Cynthia was saying. What appeared to be reasonable summary attributes. What appeared to be layout tables would be ignored anyway.
... For a layout table, whatever the content is the summary would be taken away
<Zakim> chaals, you wanted to note that the hiddenness *is* an accessibility feature
chaals: the hiddenness is an accessibility feature. The fact that this stuff is not plastered all over the page willy nilly is important
... we are minimizing the cognitive overload by not showing the stuff
janina: accessibility would state that it would not stay hidden
<Stevef> "The summary attribute on table elements was suggested in earlier versions of the language as a technique for providing explanatory text for complex tables for users of screen readers. One of the techniques described above should be used instead. " current text in the html5 spec says don't use it
janina: we don't want to interrupt the reading flow
<oedipus> RATIONALE: Just as use of BLOCKQUOTE to achieve a stylistic effect was DEPRECATED in favor of stylesheets in HTML 4.01, so, too, should use of TABLE for layout and stylistic purposes should be DEPRECATED in favor of stylesheets
chaals: in the broad view the cognitive overload matters
cynthia: when I said design I also meant usability concerns
matt: sometimes you need hidden meta data to recover from problems
dsinger: if it is a feature for the rest of the world we should let the HTML working group here. the html working group state that it may be shown. we could say that it be visible in certain scenarios - like tools
<AllanJ> agree with chaals, provided the information is 'revealable' to the user by the User Agent
cynthia: this may be a way out of this morass
... when we had alt text shown for tooltips this changed how authors supplied alt text
rich: I think we should require that summary being shown should be a browser function based on user demand that they be revealed
Allanj: I agree. it may be useful for some people. We are looking for this in the user agent guidelines.
Rich: I think there should be some sort of reveal function to show more information about content.
janina: why should a person with a disability be the only person that has access to the additional information
<oedipus> ported TABLE layout deprecation page to HTML A11y TF wiki: http://www.w3.org/WAI/PF/HTML/wiki/Table/layout_TABLE_deprecation
cynthia: so this a mechanism for browsers where they SHOULD provide a feature that shows summary
janina: so it seems that we have agreement as to what this proposal should say
<oedipus> TWO MINUTE WARNING
cynthia: the first thing is to update the change proposal and send it to our list and Ian in particular to see that people can sign up for this
<oedipus> jim, that's why i use the @summary is to @longdesc as CAPTION is to @alt
Allanj: we should say this is human useful metadata. There are things that we want machines to know about. although there are things that users may need to know about.
cynthia: may I have permission to modify the change proposal to incorporate this feedback.
janina: 14th of January?
<scribe> ACTION: cynthia create revised summary proposal for January 14th, 2010 [recorded in http://www.w3.org/2009/12/17-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-3 - Create revised summary proposal for January 14th, 2010 [on Cynthia Shelly - due 2009-12-24].
happy new year
<kliehm> sorry, I had to go to the HTML WG telcon. I'll write my @summary ideas to the list
janina: we will resume January 7