W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Minutes HTML-A11Y Task Force 13 September 2012

From: Michael Cooper <cooper@w3.org>
Date: Thu, 13 Sep 2012 12:08:50 -0400
Message-ID: <50520512.9050103@w3.org>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Minutes of the 13 September 2012 HTML Accessibility Task Force meeting
are posted to http://www.w3.org/2012/09/13-html-a11y-minutes.html and
copied below.


  HTML Accessibility Task Force Teleconference


    13 Sep 2012

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


    Attendees

Present
    David_MacDonald, Janina_Sajka, Cooper, John_Foliot, Philippe, Judy,
    Cynthia_Shelly, Stevef
Regrets
    Laura_Carlson
Chair
    Janina_Sajka
Scribe
    MichaelC


    Contents

    * Topics <http://www.w3.org/2012/09/13-html-a11y-minutes.html#agenda>
         1. Issue-204 Status and Concerns Discussion
            <http://www.w3.org/2012/09/13-html-a11y-minutes.html#item01>
         2. Issue-30 Status & Next Steps
            <http://www.w3.org/2012/09/13-html-a11y-minutes.html#item02>
         3. Issue-31B (Sec. 4.8)
            <http://www.w3.org/2012/09/13-html-a11y-minutes.html#item03>
         4. Issue-206 Open Discussion
            <http://www.w3.org/2012/09/13-html-a11y-minutes.html#item04>
         5. The Task Force at the TPAC
            <http://www.w3.org/2012/09/13-html-a11y-minutes.html#item05>
    * Summary of Action Items
      <http://www.w3.org/2012/09/13-html-a11y-minutes.html#ActionSummary>

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

<trackbot> Date: 13 September 2012

<janina> trackbot, start meeting

<trackbot> Meeting: HTML Accessibility Task Force Teleconference

<trackbot> Date: 13 September 2012

<janina> ce Teleconference

<scribe> scribe: MichaelC

<Stevef> janina: yes will be there soon

<Stevef> client work...


      Issue-204 Status and Concerns Discussion

js: to recap, there was a Formal Objection

followed by some alternate proposals

chairs have agreed to incorporate one of those

which is in the draft now

will continue to refine that as needed

that version does not contain the substance on which PFWG objected

Tim has sent a note of encouragement

possibly in lieu of any further formal response to the objection

http://www.w3.org/mid/843B736C-BD48-425C-99CD-795FA08BA82C@w3.org

plh: this has been incorporated by editor

jb: yes, though has taken further suggestions that had not been vetted
by the groups

<plh> http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute

<Judy> jb: we will be reviewing the additional changes

js: any issues to explore based on the new language?

jf: consider a hyperlink in a table header that is hidden with @hidden

which is a real world design pattern

this could lead to tab-focusable element that is not visible

one way to address would be to declare that non-conforming and raise a
validation error

another would be to specify that hidden content that is referenced
should be exposed to user

perhaps like show / hide navigation tools are done or something

js: language encourages accessibility APIs to add support for exposing
semantic richness to assistive technologies

is there any limit to the kinds of semantics this would encompass?

i.e., would it be possible to deal with hyperlinks across full range of
assistive technology?

cs: hyperlinks would get flattened because of display:none

authors should not reference hidden content that contains structure or
active elements

jf: but if we expose full semantics, isn't a link part of that?

cs: if accessibility APIs support rich semantics and interactive elements

then it would be possible to show content and navigate hyperlinks

UI might be like summary/details (just a suggestion)

a lot of work needed to make this happen

js: so the object assistive technology knows about is provided by the
user agent

cs: if I were designing, would put the rich content in the DOM and the
accessibility API

could just put in the accessibility API, but wouldn't be
visible/navigable by mainstream users

jf: consider a screen reader that is also a screen magnifier

should work for this

cs: I would access accessibility API, open a window, instantiate a
browser instance, build a DOM, and render it

either the assistive technology or the browser could build the UI

jf: concerned that if this remains underspecified we'll have pain

I used to argue against @accesskey because of lack of discoverability

that same argument has been applied to @longdesc more recently

so really concerned about suggesting a technique that doesn't specify
discoverability

js: discoverability is a new aspect of this we need to address

but meanwhile on the hyperlink question

jf: WCAG 2 requires hyperlinks have visible focus

js: CS has given a path to that

cs: there is a lot of work to be done

since it's not done, it's vague in the spec right now

but if you or someone proposes a UI, that would be a helpful contribution

js: so what is exposed to the accessibility API has a full set of DOM
features?

cs: yes, it's just a subtree

js: to test limits

would canvas, video work?

cs: no technical reason it can't work

may not be good idea in practice

but that's a design pattern issue

jf: I'm just worried that this is so under-specified

worried this could be a technique that allows willful violation of WCAG

js: first step is somethign that works, whether it's a good idea is separate

sf: hearing that assistive technology could just build an alternate UI

some assistive technology have a range of alternate views

right now it's vague

don't see this aspect being dealt with in short term

there are so many other features to implement

so shouldn't get stuck on this feature right now

js: moving on to discoverability issue

one use case covered a lot by Rich, where intent of hidden content is to
stay hidden to all users for some specific reason

so author is controlling, and wants control over, when it's exposed

while we want programmatic discoverability so assistive technology can
tell user "there's something hidden there"

which is a clash

shouldn't leave this to UI implementation

need a flag that addresses both use case

cs: hidden content not referenced by an IDREF should be just hidden

hidden content referenced by an IDREF is associated with the referring
element

is a property of that element, as it were

so should be exposed in that circumstance

browser can tell which of those situations you're in

jf: sounds like presence of an IDREF switches the value of the @hidden
attribute

cs: sort of

like display:none where in certain circumstances the accessibility API
is populated

if author didn't want that, they wouldn't reference the object

<scribe might have missed some details here>

author could choose to only set e.g., @aria-describedby when they want
the association to be made, so it's fully hidden until the IDREF exists

jf: I guess sort of works

cs: addresses showing content when author not expecting

would like to see some code samples exploring these use cases

js: Steve, thoughts?

sf: +1 to CS

note that assistive technology do what they want anyways

defining doesn't mean they'll follow

js: so propose we should put something about this into the section

since it addresses use cases and defines how software can tell which use
case applies

cs: author turns on ability for user to access hidden content by adding
IDREF

js: please make proposal around this

cs: will do

dmd: +1 to CS


      Issue-30 Status & Next Steps

jb: back on 204, note Sam clarified on list that potential removal of
ARIA from HTML spec no longer under consideration
... on HTML-ISSUE-30

note HTML-ISSUE-204 was part of a dependency chain leading back to this

this TF has twice confirmed support for a change proposal worked up by
Laura Carlson

<Judy> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

neither the position nor details have changed

but did review some updated text from the text sub-team

to better explain the supporting evidence

and pulled in information from the requirements page

needed to add a statement about dependency chain

now HTML-ISSUE-204 progressing, we have something we can say

<Judy> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc

little more cleanup to do on the change proposal

<Judy> the subhead should now read: Relation to Issue 204 and ARIA
describedby

expect that to be in soon

removes reference to formal objection from the subhead

comments?

would like to get review and ready for HTML WG survey within a few
business days

intent was to be matter-of-fact and orient better

to the evidence etc.

would like this language in place by early-to-mid next week

expect call for updated consensus of TF mailing list today

at next text sub-team meeting, would review comments

invite TF members to join the call (Tuesday 18 Sep 2012 17:00 UTC)

objection to this process?

<Stevef> no objection

<JF> +1 to Judy's proposal

so plan to confirm updated consensus at that meeting, not wait for
following TF meeting

<Judy> this would specifically be with the changed subhead as well.

mc: any TF member can make the edit

jb: Laura has been making changes, prefer to keep on her plate

<Judy> s/keep her on plate/let her do that/

js: input?

trying to make a helpful change, time-sensitive

<Judy> jb: survey will go out before 1pm, we'll need to change it in the
wiki before then


      Issue-31B (Sec. 4.8)

js: now other issues clearing out of the way, we can look at this more

need to bring HTML chairs / WG up to speed with the advice that
conflicts with WCAG and the alternate version Steve prepared

want to leave that with just lexical definition of @alt, let the other
resources talk about usage

also there are examples that don't use alt text well

want to provide suggestions for improving it

need some people to help with that, shouldn't be too hard

jb: the priority is the first part of this, related to guidance

dmd: expect to discuss details with you soon

js: DMD is lead author in highlighting where the advice conflicts


      Issue-206 Open Discussion

js: not sure if this is in active debate

the meta generator language has been approved to be removed (not sure if
that edit is made yet)

<Stevef> issue 206 is quiet at the moment

should explore whether substitute language should go in

any active discussion?

jf: haven't seen activity on list

js: there have been circumstances in which a validator shouldn't
penalize missing alt when the authoring tool couldn't do anything about it

has a case been made to talk about this in the document?

could mean the conditions for validation change

meaning a static element in the document might not be up to date

sf: no discussion of that

js: will bring that proposal up

note there's exploration of taking this to HTML.next


      The Task Force at the TPAC

js: TF has no separate time at the Technical Plenary, but typically
meets as part of the HTML WG meeting on Thur / Fri that week

will ask more and more about agenda for that

trackbot, end meeting


    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.136 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2012/09/13 16:08:47 $

-- 

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, 13 September 2012 16:09:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 September 2012 16:09:46 GMT