- From: Mark Sadecki <mark.sadecki@gmail.com>
- Date: Thu, 21 May 2015 12:06:41 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-ID: <CAOego5NWDMREAz3i9vBiMseVF2W7OqdAd+i5PFY0vgEmWg5RYw@mail.gmail.com>
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