HTML-A11y Minutes for 17 December

Minutes from today's HTML Accessibility Task Force teleconference are
available in text belowand as html at:
http://www.w3.org/2009/12/17-html-a11y-minutes.html

   W3C

                                                           - DRAFT -

                                          HTML Accessibility Task Force Teleconference

17 Dec 2009

   Agenda

   See also: IRC log

Attendees

   Present
          dsinger, kliehm, AllanJ, Cooper, Gregory_Rosmaita, Janina, Wendy, Rich_Schwerdtfeger, +0127320aaaa,
          Cynthia_Shelly, Matt_May, [Microsoft], Laura, Stevef, Michael_Cooper, Janina_Sajka, Jim_Allan, David_Singer,
          Wendy_Chisholm, Steve_Faulkner, Henny_Swan, Martin_Kliehm, Paul_Cotton, Charles_McCathieNevile, Laura_Carlson

   Regrets
          Ben_Caldwell, Eric_Carlson, Laura_Carlson, Stephane_Deschamps, Markku_Hakkinen, Gez_Lemon, Sylvia_Pfeiffer,
          Marco_Ranon

   Chair
          Janina_Sajka

   Scribe
          Stevef, Rich

Contents

     * Topics
         1. @summary for TABLE
     * Summary of Action Items
     __________________________________________________________________________________________________________________



   <trackbot> Date: 17 December 2009

   <janina> regrets for december 17

   <janina> regrets eric_carlson

   <janina> regrets John_Gunderson

   <janina> regrets Marco_Ranon

   <janina> regrets stephane_deschamps

   <janina> regrets Markku_Hakkinen

   <janina> regrets Ben_Caldwell

   <Stevef> scribe:Stevef

   <janina> ~Meeting: HTML-A11Y telecon

   <janina> Chair: Janina_Sajka

   <janina> agenda: this

   <oedipus> new wiki pages:

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

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

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

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

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

   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

   <Stevef> scribe: Stevef

   <richardschwerdtfe> matt: Hixie's statements that some were harmful were incorrect in my mind.

   cyns: haven't seen people going bthrough and checking crawls

   <richardschwerdtfe> cynthia: I have not seen people that went through the calls that said whether the summaries were
   useful

   <richardschwerdtfe> cynthia: for example calendar, search results, main content, mp3 downloads, ... many of these were
   useful as summaries

   yes:

   I have

   <richardschwerdtfe> cynthia: has anyone spent time going through these?

   <richardschwerdtfe> 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

   also many 'bogus' summarys are never heard by AT users as they are on layout ttables that are ignored by AT

   <richardschwerdtfe> matt: it easy to pick out things that do what they were intended to do.

   <richardschwerdtfe> cynthia: I did not go through the whole thing. The most common summary was calendar

   <richardschwerdtfe> cytnthia: i did not do a percentage but half were useful which is different from the impression
   that others gave.

   <richardschwerdtfe> janina; 50 percent is very good

   <richardschwerdtfe> cynthia: they did identify the table pretty well

   <richardschwerdtfe> cynthia: banner, etc. was a good chunking mechanism. I need someone from the HTML working group
   that can help me surface this.

   <richardschwerdtfe> steve: if that information is in the hidden meta data that is good.

   <richardschwerdtfe> 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?

   <richardschwerdtfe> janina: the hiddenness is not the accessibility feature.

   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

   <richardschwerdtfe> 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

   <richardschwerdtfe> cynthia: Am I correct in the disability community is that the concern is the validator warnings.

   <richardschwerdtfe> janina: yes, as it tells the author they can't do this

   <richardschwerdtfe> janina: 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

   <richardschwerdtfe> janina: we perhaps could engineer a better summary

   <richardschwerdtfe> Janina: we need to move through a phase of re-engineering

   <richardschwerdtfe> janina: the wording is not good

   <richardschwerdtfe> 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.

   <richardschwerdtfe> Steve: 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

   <richardschwerdtfe> chaals: the hiddenness is an accessibility feature. The fact that this stuff is not plastered all
   over the page willy nilly is important

   <richardschwerdtfe> chaals: we are minimizing the cognitive overload by not showing the stuff

   <richardschwerdtfe> q

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

   <richardschwerdtfe> janina: accessibility would state that it would not stay hidden

   "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

   <richardschwerdtfe> 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

   <richardschwerdtfe> chaals: in the broad view the cognitive overload matters

   <richardschwerdtfe> janina: sure

   <richardschwerdtfe> cynthia: when I said design I also meant usability concerns

   <richardschwerdtfe> matt: sometimes you need hidden meta data to recover from problems

   <richardschwerdtfe> 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

   <richardschwerdtfe> cynthia: this may be a way out of this morass

   <richardschwerdtfe> cynthia: when we had alt text shown for tooltips this changed how authors supplied alt text

   <richardschwerdtfe> rich: I think we should require that summary being shown should be a browser function based on user
   demand that they be revealed

   <richardschwerdtfe> Allanj: I agree. it may be useful for some people. We are looking for this in the user agent
   guidelines.

   <richardschwerdtfe> Rich: I think there should be some sort of reveal function to show more information about content.

   <richardschwerdtfe> 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

   <richardschwerdtfe> cynthia: so this a mechanism for browsers where they SHOULD provide a feature that shows summary

   <richardschwerdtfe> janina: so it seems that we have agreement as to what this proposal should say

   <oedipus> TWO MINUTE WARNING

   <richardschwerdtfe> 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

   <richardschwerdtfe> 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.

   <richardschwerdtfe> cynthia: may I have permission to modify the change proposal to incorporate this feedback.

   <richardschwerdtfe> janina: 14th of January?

   <richardschwerdtfe> cynthia: yes

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

   <richardschwerdtfe> 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].

   <richardschwerdtfe> happy new year

   <kliehm> sorry, I had to go to the HTML WG telcon. I'll write my @summary ideas to the list

   <richardschwerdtfe> janina: we will resume January 7

   <richardschwerdtfe> zakime, by

Summary of Action Items

   [NEW] ACTION: cynthia create revised summary proposal for January 14th, 2010 [recorded in
   http://www.w3.org/2009/12/17-html-a11y-minutes.html#action01]

   [End of minutes]
     __________________________________________________________________________________________________________________

Scribes: Stevef, Rich
Present: dsinger kliehm AllanJ Cooper Gregory_Rosmaita Janina Wendy Rich_Schwerdtfeger +0127320aaaa Cynthia_Shelly Matt_May [Mi
crosoft] Laura Stevef Michael_Cooper Janina_Sajka Jim_Allan David_Singer Wendy_Chisholm Steve_Faulkner Henny_Swan Martin_Kliehm
 Paul_Cotton Charles_McCathieNevile Laura_Carlson
Regrets: Ben_Caldwell Eric_Carlson Laura_Carlson Stephane_Deschamps Markku_Hakkinen Gez_Lemon Sylvia_Pfeiffer Marco_Ranon
People with action items: cynthia

-- 

Janina Sajka,	Phone:	+1.202.595.7777;
		sip:janina@CapitalAccessibility.Com
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Thursday, 17 December 2009 17:07:59 UTC