See also: IRC log
<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
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
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.[End of scribe.perl diagnostic output]