Re: HTML-A11y Minutes for 17 December

I posted this in the IRC channel but it was not tracked in the 

(17:47:00) 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 <caption>. 
[Sorry for the interruption.]

LH

Janina Sajka, Thu, 17 Dec 2009 12:07:28 -0500:
> 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 18:11:15 UTC