Minutes HTML-A11Y Task Force 18 October 2012 from Michael Cooper on 2012-10-18 (public-html-a11y@w3.org from October 2012)

From: Michael Cooper <cooper@w3.org>
Date: Thu, 18 Oct 2012 14:49:17 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <50804F2D.7000509@w3.org>
Minutes of the 18 October 2012 HTML Accessibility Task Force meeting are
posted to http://www.w3.org/2012/10/18-html-a11y-minutes.html and copied
below.


  HTML Accessibility Task Force Teleconference


    18 Oct 2012

Agenda
<http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0108.html>

See also: IRC log <http://www.w3.org/2012/10/18-html-a11y-irc>


    Attendees

Present
    John_Foliot, hober, Janina, Judy, Michael_Cooper, Cooper, Cynthia_Shelly
Regrets
    leonie
Chair
    Janina_Sajka
Scribe
    Judy, MichaelC


    Contents

    * Topics <http://www.w3.org/2012/10/18-html-a11y-minutes.html#agenda>
         1. Sec. 7.1 Hidden
            http://htmlwg.org/heartbeat/WD-html5-20121011/editing.html#the-hidden-attribute
            <http://www.w3.org/2012/10/18-html-a11y-minutes.html#item01>
         2. Poster Alt Redux
            http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0062.html
            <http://www.w3.org/2012/10/18-html-a11y-minutes.html#item02>
         3. Subteam Reports: Bug Triage; AAPI Mapping; Text
            <http://www.w3.org/2012/10/18-html-a11y-minutes.html#item03>
         4. The Task Force at the TPAC
            <http://www.w3.org/2012/10/18-html-a11y-minutes.html#item04>
         5. Other Business
            <http://www.w3.org/2012/10/18-html-a11y-minutes.html#item05>
    * Summary of Action Items
      <http://www.w3.org/2012/10/18-html-a11y-minutes.html#ActionSummary>

------------------------------------------------------------------------

<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


      Sec. 7.1 Hidden
      http://htmlwg.org/heartbeat/WD-html5-20121011/editing.html#the-hidden-attribute

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


      Poster Alt Redux
      http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0062.html

jf: my questions no longer concerns, have withdrawn formal objection


      Subteam Reports: Bug Triage; AAPI Mapping; Text

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


      The Task Force at the TPAC

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


      Other Business

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


    Summary of Action Items

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.137 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2012/10/18 15:57:57 $


-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>
Received on Thursday, 18 October 2012 18:56:57 UTC