W3C home > Mailing lists > Public > public-html-a11y@w3.org > June 2010

Minutes from ARIA Mappings Subteam, Tuesday 15 June

From: Janina Sajka <janina@rednote.net>
Date: Tue, 15 Jun 2010 16:24:36 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20100615202436.GE2109@sonata.rednote.net>
Minutes from today's HTML-A11Y Task Force ARIA Mappings Subteam meeting
are provided in text below and in html at:
http://www.w3.org/2010/06/15-aria-minutes.html

   W3C

                                                           - DRAFT -

                                                  ARIA mapping - HTML A11Y TF

15 Jun 2010

   Agenda

   See also: IRC log

Attendees

   Present
          Michael_Cooper, Stevef, Rich, Janina, Cynthia_Shelly, [IPcaller]

   Regrets
   Chair
          Steve_Faulkner

   Scribe
          cyns, janina

Contents

     * Topics
     * Summary of Action Items
     __________________________________________________________________________________________________________________

   <cyns> http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

   <Stevef> http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

   <cyns> how do I make myself scribe?

   <cyns> SF: schould we use ARIA or WAI-ARIA in the doc?

   <MichaelC> scribe: cyns

   JS: I think it's WAI-ARIA

   SF: we have 2 tables. the first one used to be called strong native semantics. I changed it to elements with base
   sematnics that cannot be overridden

   this first table is pretty much what's in the spec. The second table is elements with semantics than can be overriden

   this table is the things we've talked about before

   RS: did we call the button role?

   <Stevef> i am here

   <Stevef> i can hear

   <Stevef> i will call back in

   ok. thanks.

   RS: si this waht we agreed to for details?

   CS: I thought the summary child was the button

   RS: implied semantics for details is that its labeled by summary
   ... we also found some bugs with the spec, that we need to address such as bug 92

   SF: There are places where we still need to make decisions.
   ... we also need to address places where we don't agree with the restrictions.

   CS: should we just start at the top?

   RS: where we allow people to override, does this mean or, that is you cna have either one
   ... look at details. it's a reveal button. it reveals an area.
   ... it's only a combobox if someone decides to override it and make selectable entries inside it.
   ... we're saying what it can be overridden by.

   SF: restrictions are what it can be overriden with.

   RS: ok
   ... do we want to say that it controls the section that it's expanding.

   SF: it could, but that's not what this table is about

   RS: i meant the implied semantics

   SF: we can put that in as well.

   CS: do we want to?

   SF: if they're helpfu we can add them in
   ... the main thing about the second table is that it has a lot fo things that used to be in the first table because
   there were more restrictions.
   ... what i need you to do is to go through and say if you agree of disagree, and bring it up and why.

   <janina> scribe: janina

   rich: input type should say what indeterminate is

   steve: yes, but separate from what we're doing here

   <cyns> i'm back

   steve: an aria check on a standard html checkbox should be quite rare

   <cyns> it's probably going to be pretty rare where a standard html text box is going to have an aria-checked on it?

   cyns: seems like an easy beginner's mistake, though

   <cyns> CS: inexperienced authors may make that mistake.

   cyns: perhaps having both should be a warning

   steve: yes
   ... please read guidance for conformance checkers ...

   sf: first, metadata content ...

   cs: makes sense

   rs: yes

   sf: second table, anything form associated or interactive
   ... so, error if overwritten

   cs: agree, but might want to say 'specified in the table above' or similar

   sf: a warning if something other than what's allowed goes for the first table, which is more restrictive

   cs: might be helpful to make our purpose more explicit

   rich: are we saying validators must support a b and c -- is this what html-wg wants?

   <Stevef> i can hear you

   <Stevef> i will ring in on another phone

   sf: spec has referred to error/warning conditions, so i've based on our dicusssions
   ... tried to provide useful author guidance as well

   cs: pretty subtle, but i like it
   ... think you're on the right track

   rs: due when?

   js: next week--the 24th

   sf: obviously i agree with all this, i put it there
   ... can you all send a list of what you disagree? and we can focus on that?

   cs: yes

   rs: not today--will do my best

   sf: think we're closer than last week?

   rs: yes
   ... we need a list of issues related to this to submit--e.g. bug 9817

   <richardschwerdtfe> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9817

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

Scribes: cyns, janina

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

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 Tuesday, 15 June 2010 20:25:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:12 GMT