PF's HTML Caucus Draft Minutes for 2 October

Minutes from today's HTML Caucuse teleconference are provided in text
below, and are available in html at:
http://www.w3.org/2009/10/02-pf-minutes.html

   W3C

                                                           - DRAFT -

                                                     PF/HTML_Caucus telecon

02 Oct 2009

   See also: IRC log

Attendees

   Present
          Janina, Cooper, Joshue, Stevef, Cynthia_Shelly

   Regrets
   Chair
          Janina_Sajka

   Scribe
          janina

Contents

     * Topics
         1. Moving the API call
     * Summary of Action Items
     __________________________________________________________________________________________________________________



   <janina> agenda: this

   <scribe> ScribeNick: Joshue

   TOPIC

   JS: There is a request for consensus on our joint TF on a11y
   ... Members should reply. PF have discussed who our rep could be. The minutes seems unfinished

   MC: Maciej said he had overlooked a couple of things - revised call for consensus. He says he has sent it. The new
   period is next Thurs. We are delayed by a week again.

   JS: Ok

   <process discussion>

   <Laura> Call for HTMLWG volunteers for accessibility task force facilitator

   <Laura> http://lists.w3.org/Archives/Public/public-html/2009Sep/1202.html

   JS: What do you sense from the meeting?

   CS: No one said anything about that (last call). They are working on the process but the doc is not ready.

   SF: They won't have it ready in four weeks. Hixie is closing down issues from the bug tracker, some things are moved to
   HTML issue tracker. We'll see.

   JS: Anyone have a pointer to MS extensibility proposal?

   SF: I'll find it and post it.

   <Laura> Distributed Extensibility Submission from Microsoft - 30 September 2009

   <Stevef> html issue 41 Decentralized-extensibility http://www.w3.org/html/wg/tracker/issues/41

   <Laura>
   http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm

   thanks Laura

   JS: That will help
   ... We need to figure out facilitators etc we will work it out. I want to discuss that with Judy as she is very
   involved in this on behalf of the TF.
   ... I hope we are soon at the end of the HTML WG process, and we are looking at the time for the call. This or some
   other hour.

   SF: Opera responded to Maciejs email - to say they support it

   JS: Good

   <Laura> Opera's support: http://lists.w3.org/Archives/Public/public-html/2009Sep/1210.html

Moving the API call

   CS: Steve would you be up for moving the call an hour earlier?

   SF: Yes

   <janina> http://www.w3.org/mid/824e742c0908171632j77c6551fh66bfbe50a269b4f2@mail.gmail.com

   <janina> scribe: janina

   lg on 3.2.1

   lg: do not use elements/attribs/values other than as intended
   ... does this forbid ARIA? Could it be misconstrued that way?

   sf: current spec fairly clear about aria use
   ... lg's question should be considered vis a vis what the spec currently does say about ARIA

   mc: think lg looked at this when there was no aria integration yet in html spec
   ... phps this is where strong vs weak semantics is described

   sf: may i say i have concerns re strong vs weak?

   cs: please elaborate

   sf: e.g. form control, text box, would be strong and not overwritten
   ... but when part of popup would be different

   cs: true, phps we need an inheritance model

   sf: <li> elements not overwritten

   cs: phps a limited number, checkbox, etc

   sf: yes, a limited set should be mappable
   ... any element may have something like 'onclick' attached,
   ... if on heading, isn't it more important to know about the heading?

   cs: button, checkbox, radio, select ...
   ... i've been reading interactive elements section; they already have this concept
   ... think apple wrote this section--feels like apple
   ... treat menu items as buttons
   ... already have the concept of dependence on context

   sf: many of the new controls, because there's no description of how invoked, will depend on implementation

   js: isn't that a bug?

   cs: think so.
   ... think color picker will have this problem

   sf: spec generally doesn't want to define ui -- whether a button should be a button, etc

   <Joshue> +q

   js: seems to me a basic principle for at is standardization under the hood and let browsers compete on look & feel and
   clever functionality

   jo: seems the more edge cases come to the fore which are problematic will demonstrate the problems of this

   cs: there two kinds of semantics here ...

   <Joshue> -q

   cs: not override api mapping
   ... and dom mapping
   ... i believe text level things should be overwritable
   ... that's not about building an ui
   ... bot form elements build ui, and overwriting could quickly create problems
   ... text box is so generic, may need overwrite often
   ... text processing not generally through api, so not problem for at

   <Joshue> interesting point cynthia - again it depends on context of use. Maybe seperating document semantics from more
   input controls type things would help?

   jo: separating doc semantics from input controls is the disconnect here
   ... does this help us understand what we need?

   cs: yes, and html originally a doc lang

   js: returning to lg's point ... consensus that no longer an issue as aria addressed sufficiently in html spec

   lg: on h group

   jo: some thoughts, just now looking at ...

   <Joshue> http://dev.w3.org/html5/spec/semantics.html#sections

   jo: huge number of new elements ..

   <Joshue> 4.4.7 The hgroup element

   <Joshue> How will that work in practice with screen readers? Will child headings contained in the <hgroup> be ignored?
   In particular legacy UAs? Will legacy UAs just not parse the <hgroup> element and just parse the contained headings?

   <Joshue> Here s asample

   <Joshue> <hgroup>

   <Joshue> <h1>The reality dysfunction</h1>

   <Joshue> <h2>Space is not the only void</h2>

   <Joshue> </hgroup>

   <Joshue> <hgroup>

   <Joshue> <h1>Dr. Strangelove</h1>

   <Joshue> <h2>Or: How I Learned to Stop Worrying and Love the Bomb</h2>

   <Joshue> </hgroup>

   <Joshue> I don't know if this should be correct?

   mc: seems to address title plus subtitle, but they're really just the title.

   <Joshue> yes

   mc: we also have this problem in w3.org
   ... this would be confusing to current at, but phps needs to be resolved

   sf: doesn't h2 will be seen as separate heading?

   <Joshue> Yes, Steve. The spec states "The point of using hgroup in these examples is to mask the h2 element (which acts
   as a secondary title) from the outline algorithm."

   mc: this says don't put auxiliary content in the main h

   jo: if at learns this is parsed differently, that's fine, but believe this may be problematic for at that doesn't
   support h group
   ... possibly not a big issue

   mc: seems h group offers more clarity for sub headings

   <Joshue> I guess that its use makes sense it AT can handle it correctly

   consensus here is no problem with h group

   sf: what was lg's concern?

   mc: that we'll have to adjust headings guidance
   ... we'll have to adjust lots of guidance, because html5 is new, and there will be many 5 vs earlier issues

   lg 3.1.2 elemnts in dom -- already a different section number

   cs: part of command elements -- and they are labeled, have both text and icon
   ... possibly it's elsewhere, but in commands it's ok

   mc: seems ok

   cs: actually nice that every command can have label and icon
   ... if label attrib not required, we should ask for that

   lg; next is 3.2.3.2 -- still valid as of date

   lg: recommended uses of title esp subtrees

   mc: we've always had this problem, is this an opportunity to fix/

   sf: issue?

   <Joshue> I agree about trying to fix the @title. Or at least work out what we should be doing with it.

   mc: that data important for at is recommended for title

   sf: i've been on this, it's moved to tracker
   ... bug is alg for defining conforming images -- a non empty title is one you can have
   ... ok for at, since title becomes accessible name without alt
   ... visual users with keyboard can't access
   ... not displayed like alt
   ... suggest remove from alg or change advice for title

   mc: suspect html4 had this listed for lack of better knowledge

   cs: way it's done in command is correct

   <Stevef> document conformance and device dependent display of title attribute content
   http://www.w3.org/html/wg/tracker/issues/80

   lg: next 3.2.3.7 style attrib
   ... we should be sure this doesn't contradict wcag -- but may be it's ok

   mc: more a wcag techniques question
   ... personally don't care for hidden text -- bad design and a maint problem

   cs: also controversial

   consensus this is not html, but wcag adjustment

   sf: my concern is it may be hidden from at as well

   mc: phps more reliance on css media types in wcag techniques

   sf: does any at support media types?

   mc: this is actually exploiting a bug
   ... better to have better style sheed and media types support

   lg: 3.2.3.8 embedding custom nonvisible
   ... suggest we can ignore if we want -- may not be a11y

   sf: this is about stopping an extention point
   ... can put js data binding, but not a back door extensibility
   ... that's why it's there

   js: so better to have a defined extensibility mechanism

   mc: specs define what's conforming, not what works

   so ... title attribute and making label required are our two actions to escalate from lg's comments?

   consensus

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

Found ScribeNick: Joshue
Inferring ScribeNick: janina
Present: Janina Cooper Joshue Stevef Cynthia_Shelly

-- 

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 Friday, 2 October 2009 16:13:39 UTC