<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

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: Joshue
Found Scribe: janina
Inferring ScribeNick: janina
ScribeNicks: Joshue, janina
Default Present: Janina, Cooper, Joshue, Stevef, Cynthia_Shelly
Present: Janina Cooper Joshue Stevef Cynthia_Shelly
Got date from IRC log name: 02 Oct 2009
Guessing minutes URL: http://www.w3.org/2009/10/02-pf-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.