See also: IRC log
<trackbot> Date: 18 October 2012
<janina> trackbot, start meeting
<trackbot> Meeting: HTML Accessibility Task Force Teleconference
<trackbot> Date: 18 October 2012
<janina> Meeting: HTML-A11Y Task Force Teleconference
<Judy> scribe: Judy
JS: Where should we track the latest version of the lang?
TOC: Latest editor's draft.
CS: I started a thread last week, set of events and methods that shouldn't work, couple of comments, happy to discuss live.
JS: JF and TOC here, RS is not. Possibly discuss.
JF: Thx Cynthia. Looks good.
Where is that effort going? Note it in the text, that those
events should be disabled? Need to draw attention to that in
the spec.
... Last saw it Tues this week; Ted will you be rolling it into
the Ed's draft?
Ted: Think I saw qu's from Maciej that would be worth addressing first.
JF: Posed a qu to Maciej, don't know if was responded to.
CS: You could get element by ID
and click on it and that should fail.
... but so should that be called a method. Focus, blur,
shouldn't those just fail? Make sense?
<MichaelC> scribe: MichaelC
jf: can´t have anything requiring focus in hidden content
think language was that scripted form controls would still be active
it should be explicit that such things would be disabled
so you don´t get focus in there somehow
cs: yes, also for @@
sounds like a similar problem we had with shadow DOM in canvas
jf: that´s like an image map with something you don´t see behind the image
in canvas, things in sub-DOM get displayed in the visible portion
cs: maybe we could think of longer descriptions as being more like the imagemap situation
jf: the proposal to add aria-describedat would add this magic property
aria-describedby should not have that ability
I don´t oppose the former, I oppose retrofitting aria-describedby
<JF> +1 to that
cs: I always thought of describedby as like opening a new window
expected attempts to focus would fail
I´m ok with @@ but some have other views
jf: I just don´t want anything not visible to be focusable
haven´t heard of a situation where we´d want that
cs: could imagine a canvas-like situation with a subtree you should be able to work around
but not sure if that use case would come about
js: note WebApps just published Shadow DOM spec
cs: maybe that´s where we tackle this issue
js: PFWG already expects to have comments
and thinks this group should review
-> http://www.w3.org/TR/2012/WD-shadow-dom-20121016/ Shadow DOM
cs: @@
jf: so now in bug activity, discussion of CSS
currently default CSS is display:none
screen readers respect that, and don´t do anything
now we´re saying there are situations where that native CSS handling would be changed
cs: not sure that´s true for all UAs
jf: have seen a lot of dumb implementations in sites, leading to things that don´t work in practice
to me, if @hidden = display:none and you want AT to access, you have to change that default CSS
cs: if you want more than something flattened into AAPI string, yes
if we disallow method, allows structured text but not interactivity
jf: but then you have something that´s not display:none
cs: could have display:none stuff in a11y tree also
jf: my concern is these cases aren´t specified
leading to unanswered questions in the spec
and you get a variety of incompatible implementations, or no ues
cs: we previously punted to ¨until user agents¨ situation
for now, maybe disallow
and revisit later when we have v.next
when we have AAPI support
jf: great virtual beer session, but we need to resolve where this is going
js: at some point we´ll have to have two implementations
cs: won´t get that any time soon
Windows will have to be next version of OS, a ways off
this is a pretty big feature
not sure what other platforms will do
js: @@
cs: I will submit bug and reply to Maciej´s mail
the CR argument does mean v.next
js: let´s look across the board, maybe we´ll all prefer
cs: but not for 5.0 timeframe
js: so let´s consider actively for 5.1 if we want it so much
we´re not trying to throw up obstreperious roadblocks, we have real concerns
jf: understand there are real use cases
just don´t to leave things undefined
cs: so with this bug we are making non-support in HTML 5 an explicit decision
makes it an area of research for people working on v.next
changes like this depend on both OS and AT changes, long time to get both to happen
js: @@
cs: even DOM-based AT that don´t depend on AAPI have long dev cycle
jb: clarification
cs: we wouldn´t be able to exit CR with this feature by 2014
so instead of putting in an at risk feature, should move it to v.next
jb: this is about describedat?
cs: about interactive content in hidden sub-dom
toc: the open bug about @@ will drive @@
don´t expect implementation of @hidden = display:none to change
4 browsers shipped with that
so we need to figure out what that means and document it
need to figure out distinction between exposing to viewport and exposing to an API
the more detail and bugs we get, the easier it is to move forward
js: so we have next steps, can bring to agenda as needed
jf: my questions no longer concerns, have withdrawn formal objection
cs: AAPI taking out pure MSAA column and working through implications of that
after next week´s meeting, will have better idea of draft timeline
js: need memorial service for MSAA
cs: was groundbreaking at the time
jf: +1
jb: Text hasn´t met recently
no pressing issues
would be useful to meet with editors about parts 1 & 2 on David MacDonald´s review of the alternative text
perhaps just you and I could request meeting with editors per HTML Co-Chairs' suggestion
that should come from TF facilitator
mc: Bug traige hasn´t met in weeks
Hans reviewed bugs some weeks ago
found one to forward to TF
js: no formal meeting at TPAC
but a lot of us will be there
and many won´t
could raise specific issues within HTML WG meeting
js: now that Plan2014 adopted, we could start work on extension specs
jb: please read the co-chairs´ announcement
suggest the TF look at extension specs it might want to formally take up
there are some suggestions floating around, but not yet officially delegated
cs: would like making HTML to AAPI mapping doc an extension spec
the ARIA version is normative, think this should be too
js: timeframe of 5.0?
cs: not sure
js: we should review this proposal
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/+!/+1/ Succeeded: s/but/bug/ Succeeded: s/could be useful/would be useful/ Succeeded: s/just he and I/just you and I/ Succeeded: s/with editors/with editors per HTML Co-Chairs' suggestion/ Succeeded: s/zakim. ??p20 is Janina// Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: Judy Inferring ScribeNick: Judy Found Scribe: MichaelC Inferring ScribeNick: MichaelC Scribes: Judy, MichaelC ScribeNicks: Judy, MichaelC Default Present: John_Foliot, hober, Janina, Judy, Michael_Cooper, Cooper, Cynthia_Shelly Present: John_Foliot hober Janina Judy Michael_Cooper Cooper Cynthia_Shelly WARNING: Replacing previous Regrets list. (Old list: Léonie_Watson, Rich_Schwerdtfeger) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ rich WARNING: Replacing previous Regrets list. (Old list: rich) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ leonie Regrets: leonie Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0108.html Found Date: 18 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/18-html-a11y-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]