W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2015

[MINUTES] HTML Accessibility Task Force Teleconference 2015-05-21

From: Mark Sadecki <mark.sadecki@gmail.com>
Date: Thu, 21 May 2015 12:06:41 -0400
Message-ID: <CAOego5NWDMREAz3i9vBiMseVF2W7OqdAd+i5PFY0vgEmWg5RYw@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Thanks to everyone who attended the call today.   Minutes are below in HTML
and TEXT.  Happy Global Accessibility Awareness Day

HTML:
http://www.w3.org/2015/05/21-html-a11y-minutes.html

TEXT:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

              HTML Accessibility Task Force Teleconference

21 May 2015

   See also: [2]IRC log

      [2] http://www.w3.org/2015/05/21-html-a11y-irc

Attendees

   Present
          janina, Ivan, Liam, Plh, Cynthia_Shelly, Tzviya,
          LJWatson, SteveF, +1.617.319.aaaa, Mark, Judy,
          Rich_Schwerdtfeger, Joanmarie_Diggs, JF,
          +1.609.759.aabb, Michael_Cooper, Jason, ShaneM,
          mgarrish, paulc, Mike, [IPcaller], darobin, Sadecki

   Regrets
   Chair
          Charles

   Scribe
          MarkS

Contents

     * [3]Topics
         1. [4]Identify Scribe
            http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scr
            ibe_List
         2. [5]Additional agenda?
         3. [6]Extended ARIA Roles Discussion
            https://www.w3.org/WAI/PF/wiki/ARIAExtensions
     * [7]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 21 May 2015

Identify Scribe
[8]http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

      [8] http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

   <janina> Yes, thanks!

   <janina> Thanks, Robin!

   <richardschwerdtfeger> the link to the webex is not in the
   agena. please post it here

   <janina> Rich, we're on Zakim 2119

   <LJWatson> @Rich we're using zakim not WebX

   <Judy> [JB: We are continuing to use Zakim for this call. There
   will be a practice session on WebEx following this call. The
   message about that was from Liam on the list earlier.]

   <scribe> scribe: MarkS

Additional agenda?

   PLH: Anything else to discuss today? in addition to ARIA

   <richardschwerdtfeger>
   [9]https://www.w3.org/WAI/PF/wiki/ARIAExtensions

      [9] https://www.w3.org/WAI/PF/wiki/ARIAExtensions

Extended ARIA Roles Discussion
[10]https://www.w3.org/WAI/PF/wiki/ARIAExtensions

     [10] https://www.w3.org/WAI/PF/wiki/ARIAExtensions

   TS: several months ago, DPUB considered adding features to HTML
   that would improve accessibility in the context of digital
   publishing, much like DAISY does.
   ... data-* css, etc
   ... at TPAC, we decided to write an extension spec. during CFC
   for FPWD, there were many objections, so we are considering a
   different path. ARIA extensions
   ... semantic inflection for HTML

   <janina> [11]https://www.w3.org/WAI/PF/wiki/ARIAExtensions

     [11] https://www.w3.org/WAI/PF/wiki/ARIAExtensions

   RS: link for proposal to extend
   ... aria TF met and put this proposal together. it has been
   reviewed by PF. Mostly agreed with one exception
   ... if you are to write an extension for ARIA, it should not
   become part of the non-optional parts of ARIA. If a browser is
   fully compliant with 1.1, it will no longer be once an ext gets
   added
   ... what we want to say is that anything that goes into the
   core, must be compliant with Accessibility API mappings
   ... it would be a choice to implement them or not. The goal is
   to avoid breaking accessibility with these modules

   <ShaneM> as I proposed last night, the text for point 4 could
   say "Any ARIA extension specifications that have reached
   Recommendation status at the time the ARIA Core is revised and
   approved as a superseding Recommendation will be considered to
   be a part of ARIA Core and their non-optional components
   required of all ARIA conforming implementations."

   RS: formal mechanism, extending must come from existing
   taxonomy that you can inherit from. descendants of existing
   role of published spec, not WD

   <scribe> ...new states must be coordinated with ARIA TF

   UNKNOWN_SPEAKER: must have API mapping and does not break
   accessibility, doesn't have to be for accessibility, just not
   break it
   ... hyphenated role values acceptable dpub-glossary,
   ... create a normative api mapping spec
   ... demonstrate that it works with existing AT
   ... that would be the process
   ... ARIA is a cross connecting tech. Used for accessibility,
   but not limited to. allows for putting additional semantics
   into existing markup

   <ivan> [12]Current draft of the DPUB-ARIA terms

     [12] https://rawgit.com/w3c/aria/master/aria/dpub.html

   UNKNOWN_SPEAKER: valuable to CMS, epub readers, AT
   ... epub is mostly based on existing web/browser technology.
   ... should improve compatiblitliy

   PLH: SteveF? You are working on mapping in HTML. Can you add to
   this?

   SF: my concern appears to be partially resolved: prefixed
   roles.
   ... i think the existing solution is reasonable. would mitigate
   issues with collisions
   ... extension roles should have a prefix. that would be OK.

   IH: two issues that came up in early discussions with DPUB.
   What we call hyphen space, separate of terms and the scope of
   what can be a value in the role attribute. this was fuzzy
   ... comments we received were against adding new terms, or that
   there would be collisions, etc.
   ... the number of terms we have is significant.
   ... those terms, as they are in DPUB are very important
   ... what happens if hyphen-namespace solution moves forward

   TS: confused about what the method is for graduating terms from
   ext to ARIA spec
   ... suggest adding new terms after publication, and then a
   revision of aria core
   ... chapter for instance
   ... otherwise extension work has to be done in two places at
   once

   RS: hyphen-space is designed to avoid collisions with terms
   that have been in there from the start. Should be able to name
   them as they want, but can't do that without namespaces
   ... If we're not in the middle of CR, we should have them
   available immediately, and get responses from community
   immediately
   ... important if we get the API mappings, we won't be breaking
   things. We don't want to define your space.

   <Zakim> janina, you wanted to address in/out of scope issue

   JS: some of the scope challenges that we haven't addressed yet
   is whether it is just accessibility or not. We're not
   restricting to AT use, but want to make sure new terms don't
   break accessibility.

   <Zakim> ShaneM, you wanted to address adoption / requirement
   concerns and prefixing and to address tzviyas question about
   "graduating"

   SM: extension mechanisms, and how they are made part of core
   (or not). prefixing, turned into not-prefixed, etc, changing
   the name is not as helpful as agreeing on terms that work for
   everyone.
   ... how we get things into core, the model I imagined was as
   ext are ratified, published, etc, they don't become a required
   part of ARIA 1.1 core, etc, but when next version comes out,
   the new term would be part of that spec.
   ... I think that is what implementers will care about

   CS: I want to talk about ext. I like that model that was
   discussed. Also concerned about new terms in new specs. It can
   be harder to track. I conform to this, this, this, but not
   that, and that. etc.
   ... author can know what they could accomplish in that browser
   ... different than what Shane is saying. I imagined it to be
   more like CSS

   PLH: We have a long history of using prefixes on the web, and I
   think long term, they don't work out.
   ... CSS for example
   ... implementation problems
   ... at the end of the day, what matters is what gets
   implemented. i would advise not to block on what should be part
   of core

   LW: RE giving AT users ability to interact with DPUB. Too many
   roles could decrease accessibility if too many roles are
   introduced
   ... have we spoken to other implementers of ebook readers with
   their own screen readers to see if they would implement support
   for new roleS?
   ... that seems important

   <ivan> [13]EPUB Structural semantics

     [13] http://www.idpf.org/epub/profiles/edu/structure/

   TS: the terms we have discussed come from IDPF and DAISY. So
   ebook publishers are plugged into these groups and are familiar
   with these terms

   RS: IDPF, DAISY, Adobe, were all involved in EPUB, and
   accessibility was considered from the start

   TS: we can reach out to other implementers

   LW: I think it would be important to involve as many as
   possible.

   <plh> ack Shaneack Shane

   <Zakim> ShaneM, you wanted to ask cynthia about announcement

   SM: Cynthia, you mentioned wanting extensions to be optional.
   If you have things that are optional, things that are portable
   need a mechanism to announce themselves

   CS: I don't have anything in mind, but there are examples of
   support listings
   ... it needs to be deterministic.
   ... how does CSS do it?

   PLH: they don't

   <ShaneM_> I note that schema.org seems to resolve this well
   with prefixing

   CS: I understand the market doesn't like prefixes, but certain
   terms have major conflicts with existing taxonomies.

   <Zakim> SteveF, you wanted to ask PLH about aria-* prefixings
   success?

   CS: prefixing would solve that problem

   SF: Trying to understand the issue of having a prefix and then
   removing it when it gets moved to "core"

   PLH: using x- causes problems. solution was to put everything
   behind a test flag

   SF: we talked about attribute names/values/roles

   <ShaneM_> +1 that it is a TOKEN!

   SF: its a token, it doesn't need to represent what is exposed
   to the user, its just a token

   <ivan> +1 to SteveF

   SF: the concept of it becoming part of the core vocab could
   still include the hyphen or not

   RB: I wanted to point out that these are 2 diff things. Using a
   prefix is probably fine, removing it later is a bad idea. What
   happens is that devs want to be future proof, so they will
   include both dpub-foo and foo

   <Zakim> ShaneM_, you wanted to ask about core vocabulary and
   prefixes

   RB: don't want to remove prefix. If the prefix moves to core,
   that is fine.

   <richardschwerdtfeger> +1

   SM: I agree with robin on that. we need to work out a mechanism
   for moving to core and what that means.

   PLH: CSS doesn't have this problem. there is no CSS core

   SM: CSS has graceful degradation,

   <Zakim> liam, you wanted to wonder if we're going down a thorny
   path away from what AT should do, who is helped? schema.org
   only works because (1) money, (2) very limited in scope

   SM: it would be disasterous, not inconvenient

   LQ: similar to struggles in XML as well. Worry about defining
   all of these roles and nobody implementing them.

   <ShaneM_> I disagree about the scope of schema.org. it is VAST

   LQ: schema.org was mentioned, it is successful because it has
   limited scope. And there is financial incentive to adopt.
   Opposite for ARIA. If we make it more complicated, it might
   have adoption problems

   <liam> [e.g. what happens if I introduce 300 prefixed terms?]

   <SteveF> [e.g. what happens if I introduce 300 prefixed terms?]
   much better than 300 unprefixed terms

   IH: We have to have a clear view of what it means to use new
   role values. If we have new terms and DPUB reading systems use
   those terms for things that are not strictly accessibility
   issues, i.e. glossary-item, there would be a pop-up
   (universally beneficial) .
   ... this is demonstration that it is useful for providing
   additional structure to document.

   <ivan> +1 to richardschwerdtfeger

   RS: I would encourage things like that. At IBM we use aria
   semantics to drive UI because we can tie it to CSS. Makes code
   more performant. We can work with designers to create UIs with
   more semantics.
   ... if there is value in adding other ways to include semantic
   info, that is a good thing

   <tzviya> +1 to using ARIA to make code more performant

   RS: this work was taken out of DAISY, which is proven.
   Powerful, time-saving features. Universally beneficial
   ... ask that normative API mapping is created, to not break
   anything. that is all

   TS: Would love to do what IBM is doing in DPUB, but can't
   because ARIA doesn't do what we need currently.
   ... it will take time to implement, and we understand that we
   may need to include fallbacks during this time, glossary
   fallback to landmark for instance until support gets added. we
   have to start somewhere

   CS: like with IBM is doing too. great thing to do when it
   works. RE API Mappings, there is a place to put the string that
   is in the role attribute. AT can get at it. several important
   platform API developers are involved. good chance that going
   through ARIA will result in getting implementations.

   <joanie> +1 for adding API being easy in Linux

   <Zakim> SteveF, you wanted to ask Cynthia_Shelly what the
   mechanism is to add abitrary role values in UIA?

   CS: getting the APIs in sync with ARIA is not a difficult thing

   SF: Cynthia, What is the mechanism for this? I think that works
   in IA2

   CS: we have a similar method
   ... if there is something in the aria that we don't know how to
   map, there is a mechanism for getting at it.

   RS: if we want to pull things into ARIA spec, I don't see why
   we can't have a mechanism for doing that. shouldn't get hung up
   on whether or not if has a prefix. Just want to say we don't
   want to ever remove a prefix if that is what was agreed on in
   the first place

   <Zakim> janina, you wanted to ask about nonprefixed roles

   JS: We should also discuss about the possibility of using
   non-prefixed terms. Want to keep this convo going. Concern that
   there are some terms proposed that are way too general and we
   do not want them in no-prefixed space. want to make sure that
   doesn't become a pattern.

   <ShaneM_> +1 that some things will go in without prefixes

   CS: we need to be careful with general purpose terms.
   checked/aria-checked for example.
   ... they behave differently and that is bad

   <ShaneM> the checked thing is a state, not a role name

   <ivan> FPWD:
   [14]https://rawgit.com/w3c/aria/master/aria/dpub.html

     [14] https://rawgit.com/w3c/aria/master/aria/dpub.html

   <SteveF> +1 to ivan's proposal

   IH: how about if we take the DPUB document, change it for each
   of the terms to hyphen space, then we publish as FPWD. IF
   during the discussion some should be general enough to move
   into ARIA 1.1, we can do it.

   <ShaneM> +1 except not MOVED into aria 1.1. Named without a
   hyphen. Or possibly both. Some thigns are unprefixed but in the
   extension spec and not part of core immediately.

   IH: very bad message if during dev of EPUB three there is a
   delay because of this

   <tzviya> +1 Ivan's proposal

   JB: anyone on the call that hasn't spoken up that would like to
   add something?

   <Zakim> SteveF, you wanted to ask about role value prefixing

   <richardschwerdtfeger> +1 to Ivan

   JS: Not saying no, but I'm wondering if this is the best way
   forward, flagging the terms that have general applicability.
   ... i think in the past we have initially thought terms that
   were generally applicable were not.
   ... we may want to call them out in the beginning

   <LJWatson> +1 to Ivan's suggestion of moving forward in
   hyphen-space.

   IH: my proposal would be the other way around. Lots of concern
   about global or not. We define all in namespace by default.
   Then we can decide during publication process if any should be
   general non-prefixed terms

   JF: This sounds like an XML namespace reprise. I think feedback
   from browser vendors would be very valuable here.

   <SteveF> +1 to ivan

   IH: we are hyphenating the values, different than XML

   RS: I have to run this proposal through the ARIA TF. I will
   bring it up today on the call. I think this is a good way
   forward. We want to show support for moving forward.

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [15]scribe.perl version
    1.140 ([16]CVS log)
    $Date: 2015/05/21 16:03:09 $
     __________________________________________________________

     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [16] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at [17]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ARAI/ARIA/
Succeeded: s/not/no/
Found Scribe: MarkS
Inferring ScribeNick: MarkS
Default Present: janina, Ivan, Liam, Plh, Cynthia_Shelly, Tzviya, LJWats
on, SteveF, +1.617.319.aaaa, Mark, Judy, Rich_Schwerdtfeger, Joanmarie_D
iggs, JF, +1.609.759.aabb, Michael_Cooper, Jason, ShaneM, mgarrish, paul
c, Mike, [IPcaller], darobin
Present: janina Ivan Liam Plh Cynthia_Shelly Tzviya LJWatson SteveF +1.6
17.319.aaaa Mark Judy Rich_Schwerdtfeger Joanmarie_Diggs JF +1.609.759.a
abb Michael_Cooper Jason ShaneM mgarrish paulc Mike [IPcaller] darobin S
adecki
Found Date: 21 May 2015
Guessing minutes URL: [18]http://www.w3.org/2015/05/21-html-a11y-minutes
.html
People with action items:

     [18] http://www.w3.org/2015/05/21-html-a11y-minutes.html


   [End of [19]scribe.perl diagnostic output]

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 21 May 2015 16:07:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 21 May 2015 16:07:36 UTC