HTML Accessibility Task Force Teleconference -- 17 Dec 2009

<oedipus> new wiki pages:

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

<oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/#A_order

<oedipus> http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/#A_media

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,

@summary for TABLE

<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

<janina> q!

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

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009

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

<levy-aurelien> readable

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

<janina> ack

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.

<oedipus> http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0056.html

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> yes:

<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

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/Table/LayoutTABLEDeprecation

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

janina: sure

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?

cynthia: yes

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

<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

zakime, by

HTML Accessibility Task Force Teleconference

17 Dec 2009

Attendees

Contents

@summary for TABLE

Summary of Action Items