Minutes, HTML-A11Y Task Force 14 August

See http://www.w3.org/2014/08/14-html-a11y-minutes.html

Text version follows.

              HTML Accessibility Task Force Teleconference

14 Aug 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/08/14-html-a11y-irc

Attendees

   Present
          Sam, Chaals, Liam, janina_, Plh, Shane_McCarron, paulc,
          Cynthia_Shelly, [IPcaller], John_Foliot,
          Rich_Schwerdtfeger

   Regrets
   Chair
          Janina

   Scribe
          liam

Contents

     * [3]Topics
         1. [4]Identify Scribe
            http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scr
            ibe_List
         2. [5]MAUR Heartbeat
         3. [6]Longdesc
         4. [7]Picture Element Alt
            http://www.w3.org/html/wg/drafts/html/master/embedded-
            content.html#an-image-in-a-picture-element
         5. [8]ARIA 1.1 and HTML 5 -- Do gaps remain?
         6. [9]Access Key/Command
     * [10]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 14 August 2014

MAUR Heartbeat

   Janina: heartbeat: a document was published yesterday ...

   <janina_> [11]http://www.w3.org/TR/media-accessibility-reqs

     [11] http://www.w3.org/TR/media-accessibility-reqs

   <MarkS> regrets Mark_Sadecki

   expecting one more set of edits, editorial

   then media subteam believes document should be ready to move
   forward later this yer to Note status

Longdesc

   Janina: good news, we have a CR document published

   pointer is in the agenda

   we have to move forward quickly to stay in sync with HTML 5

   we're expecting a formal objection but not yet received

   next step is moving to PR

   we should review expected timeline

   we should also talk about requirements for moving from CR to PR

   <paulc> See Sam's reminder to David Singer about timing of
   longdesc:
   [12]http://lists.w3.org/Archives/Public/public-html-admin/2014A
   ug/0021.html

     [12] http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0021.html

   we need to show that each of our MUST statements is supported
   in 2 independent implementations

   we believe we have that

   bu [impl'n report] may need to be clearer

   agenda for this call:
   [13]http://lists.w3.org/Archives/Public/public-html-a11y/2014Au
   g/0018.html

     [13] http://lists.w3.org/Archives/Public/public-html-a11y/2014Aug/0018.html

   <plh> [14]https://www.w3.org/2014/08/longdesc-todos.html

     [14] https://www.w3.org/2014/08/longdesc-todos.html

   plh: due to the timeline of html5, 'cos we want to release HTML
   5 during TPAC ...

   we have to issue a cfc during CR to move to PR, rather than
   after the CR ended, but we don't have time

   so we have to issue the implementation report ready in time to
   issue the cfc

   report to be ready by next wednesday (20th)

   current impl report:
   [15]https://rawgit.com/w3c/web-platform-tests/master/html-longd
   esc/test-results.html

     [15] https://rawgit.com/w3c/web-platform-tests/master/html-longdesc/test-results.html

   chaals: I can probably get a document over the weekend that
   will have just the result we need
   ... we have a list of tests, I can fish up that list

   nine tests

   cover MUST requirements for user agents

   Janina: are there MUSTs for other things than user agents?

   chlls: we only need to show results for browsers

   plh: multifunction api exposure test result table has 6 columns

   and it's testing IE11, FF, chrome, safari, icab, with 2
   different stacks

   so how many impl'n do we have?

   chaals: so what is actually missing is DOM exposure

   we need to update this table

   the MSAA on Win is the standard accessibility API for a lot of
   stuff, still

   we don't seem to have mac support

   [qualitative statement unminuted :-) ]

   plh: so just exposing longdesc in the DOM is enough to claim
   implementation?

   chaals: [scribe could not hear]
   ... [exposure to DOM is sufficient for API exposure]

   plh: along with those tables we need some explanation on how to
   interpret the tables

   as we're going to have to repeat the explanations to the
   director

   [chaals will add information to help understand what the tables
   mean]

   <chaals> [What we should do: Make a document that has a table
   of the things we need to know, with an explanation, and then
   link to this document for more information for those who are
   interested]

   janina: we have a lot of data here not relevant to meeting the
   reqs of a w3c spec; we find it interesting but not [pertinent]

   [ok, 3pm ET/2100Alice Springs Time, IRC meeting for editing]

   Liam notes Laura reopened her issue

   <chaals> [If it is normative change, then it won't happen and
   has been resolved by the group. If it is editorial (as I think)
   then it is neither here nor there and we can try to make her
   happy if we think it is important]

   <chaals> [I don't think the level of change is problematic. But
   the statement she is asking for is untestable, and therefore I
   am not that interested in applying it]

   janina: increased accssibility is subjective

   and implicit

   jf: mostly editorial, agree, with Charles

   <chaals> [I am in favour of not doing anything to what we have]

   [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24168

     [16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24168

   <chaals> [+1 to Shane]

   shane: we're giving this way more weight than it's work, it's a
   dead horse

   <chaals> Proposed Resolution: We will not do anything with this
   editorial suggestion...

   decision: close 24168, resolution, no action

   <chaals> [i.e. we can make it wontfix, if we want, or just tell
   the director what we are doing with it]

Picture Element Alt
[17]http://www.w3.org/html/wg/drafts/html/master/embedded-content.htm
l#an-image-in-a-picture-element

     [17] http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#an-image-in-a-picture-element

   janina: we have proposed language from steve

   are we satisfied with this language?

   Resolution: accept steve's language on picture

ARIA 1.1 and HTML 5 -- Do gaps remain?

   [i.e. no action required from TF]

   [required people not present]

Access Key/Command

   Rich: we need to find out, are there any additional things that
   must go into aria 1.1 to support html5 native host language
   semantics

   I'd like to wrap up a lot of the issues for 1.1 and start
   working on v2, start building test cases

   <chaals> [There is an issue (IMHO) about whether ARIA should
   work with native UI - or alternatively define what the
   assistive technology that it deals with is, and isn't]

   Janina: [agrees with Charles]

   Rich: what do you mean by native UI?

   [the browser]

   JF: longdesc is being exposed right now but no visual rendering
   in the browser UI

   <chaals> [If ARIA only works through an Accessibility API, we
   effectively get two different interactions dependent on the
   arbitrary detail of whether the user's tools rely on that API
   or the user relies on a browser and its native functions]

   should we start looking for ways of exposing this functionality
   to more than screen readers?

   <chaals> [… and that's a pretty unpredictable situation for a
   user to be in]

   Janina: we're starting to build use cases, including from
   digital publishing

   Rich: dpub IG wants to supply structural semantics in aria
   markup and have it be dual purpose, can be exposed for
   accessibility & for epub readers,

   but want to define semantics for e.g. comic scripts with
   embedded SVG

   but we don't say what [browsers] do with it

   CS: Microsoft would like to use ARIA to impact UI

   <chaals> [We *allow* them to use ARIA on UI already…]

   Rich: ARIA has enough uptake now, advantages in browsers using
   it to influence the user experience

   Janina: how o we manage having the browser & a11y API both
   using aria?

   CS: We've been looking at allowing more scriptability from
   within JavaScript

   <chaals> [Actually, the hard bit is how do we specify what
   should be done without over-constraining the UI to the point
   where we mandate suboptimal behaviour]

   <chaals> [e.g. the definition of how to interact with native
   semantics - strong vs weak etc - is part of this work]

   [e.g. a11y api being able to manipulate the DOM, and scripts
   being able to talk to the a11y API]

   Rich: that's an ARIA 2 thing, need more consistency in APIs
   across platforms

   e.g. control pattern

   Need to pull out use cases

   roots of why we made ARIA were based on UI widgets in current
   practice at the time, it's gone way beyond that

   seems silly not to make use of it

   CS: a lot of things like screen size changes, audio interfaces,
   are much more mainstream now, not only a11y

   Rich: mobile is levelling of paying field across the board

   Janina: so this is going beyong 1.1, but we're trying to wrap
   up 1.1 for html5

   1.1 needs to move towards test cases so we can be publishing
   something in a little over a year

   this has been a fundamental conversation, we need to start
   adding use cases

   CS: it may be this goes into web events or UI spec

   Janina: as long as we dont lose the a11y we fought so hard to
   build

   [agreement]

Summary of Action Items

   [End of minutes]
-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Received on Thursday, 14 August 2014 16:39:04 UTC