See also: IRC log
<trackbot> Date: 21 May 2015
<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
PLH: Anything else to discuss today? in addition to ARIA
<richardschwerdtfeger> 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> 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> Current draft of the DPUB-ARIA terms
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> EPUB Structural semantics
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: 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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at 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, 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 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 Found Date: 21 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/21-html-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]