See also: IRC log
<mgylling> Matt Garrish will be late, stuck with a kid
<scribe> scribenick: Tzviya
Markus: The core problem is a
growing suspicion that ARIA might not be the right place for
our non-accessibility use cases. We have terms (semantics) for
specialized domains
... As we tried adding the DPUB-ARIA vocab to EPUB 3.1, and the
response we got from the EPUB community was "What about the
rest of our terms?"
... From an accessibility perspective DPUB-ARIA is valuable,
but we are unsure how to move forward. We don't want to keep
flip-flopping.
<Zakim> MichaelC, you wanted to ask if structured extensibility mechanism helps and to ask about implementation lag regardless of mechanism chosen and to ask about relationship to other
Ivan: It would theoretically possible to say that we keep DPUB-ARIA for accessibility terms and use another method for non-a11y terms. But, this is not really a viable option from an authoring persepctive.
Micheal: Would a structured
extensibibility mechanism be helpful?
... This would mean not going necessarily building it through
the ARIA WG. ARIA has been involved in some discussion in how
it should be involved in HTML. This has been in brought to
TAG.
<Zakim> MichaelC, you wanted to mention ARIA perspective on implicit ARIA semantics
Micheal: In ARIA, the concept of implicit ARIA semantics exists. A different mechanism would still perhaps have a mapping.
ivan: clarify the structured extension mechanism
rich: This is the first I've
heard of this problem. You've taken a lot of ARIA resources to
make this happen.
... We have written the mappings, and it's really close to CR.
Clearly there are other issues that haven't been addressed.
ivan: This question has been
asked many times. We have asked about the extension mechanism
numerous times. This is not new.
... We have never received a satisfactory answer
<MichaelC> https://www.w3.org/WAI/PF/wiki/ARIAExtensions
<Zakim> MichaelC, you wanted to say I´m not hearing an ultimatum, I´m hearing issues that bubbled up
Michael: we may not have understood the extent of the concerns, but we knew that there were concerns
ivan: if the revised
extensibility with HTML works out, that is fine
... we basically had the choice of doing this via extension to
HTML (a la ITS) or doing this via ARIA
... we chose role attr because we wanted the built in
a11y
... if you (ARIA) can make it so that if a given community
(DPUB) can add a list 50 terms that are not necessarily
a11y-specific, then we are fine
... "implemenatation" means different things in different
environments
... if this is in an AAM, then it means one thing, if it is
just a structural semantic for the purpose of publisher
workflow, it is a differernt story
... the implementation burden is on the publishing
community
... What we need is an agreement with the html community
rich: you have the ability to not
map the terms
... you have a prefixed role set, and if they are not mapped,
then they are ignored
Ivan: Will the WG accept that?
Rich: when you came in, you said that you wanted to support a11y, so we thought you wanted the terms mapped
<Zakim> MichaelC, you wanted to say I think the HTML extension process is realistically similar to the current ARIA extension process and to say the HTML and ARIA extension processes
Tzviya: If I add terms, and there's no mapping, does it validate? what happens to native semantics?
micahel: yes, it validates. defaults to native semantics
michael: if you create an HTML
extension of ARIA extension, can't work apart from WG, still
will take time
... if want to work apart from WG, need to do something like
create a vocabulary registry
ivan: we want something in
between
... let's suppose that someone wants to create a list of math
terms (proof, lemma, etc). What is the implementation of these
terms? The use of these terms by publishers
Rich: I think what we need to do is state in the mapping guide that anything with doc- prefix is not mapped.
<Zakim> janina, you wanted to say that blocks experienced in one group would probably come up in another
Janina: Nervous that some of the problem is in the process. If we can improve process to make this doable, then that should be what solves the problem.
<Zakim> MichaelC, you wanted to finish comments and to say a ¨dpub¨ attribute might not be a bad idea... and to say we´re struggling with general W3C process, not specific WG process
Michael: We're running into
process issues
... You're looking at semantics that don't have universal
applicability, but there is a definite need.
... I wonder if a dpub attr is what you need
... That will allow flexibility to create math, assessment, etc
terms
... You will still need API mappings
... Dealing with a broader W3C issue.
Ivan: When we began the process 2
years ago, the other alternative was html attr
... This issue came up in semantic web as well
... we went with ARIA because of a11y
... what we realize now is that the notion of implementation is
very different for some terms than others
<Zakim> MichaelC, you wanted to say ARIA module still valuable even if HTML Dpub attribute created and to say negotiation with HTML... and to mention ARIA approach on AAMs and to say I
michael: if we go the html attr route, we have not wasted work because we will be able to adapt AAM to the attr
+1
scribe: ARIA is relying heavily
on API Mappings
... we are relaxing rules a little. The need for mappings still
exists
... Some of what you are struggling with is a different
definition of implementation, which is a broader discussion
rich: if i don't have to do an API mapping, less work for me
ivan: the reason we selected the
terms in the current dpub-aria document is that they are the
basic terms
... if we want to have a separate document tomorrow with no
mappings, do we have a mechanism?
mgylling: anything with a doc- prefix that is not mapped is OK? Does that essentially mean that we define doc-*?
ivan: it's not that everything is acceptable, but we can write additional specs that go through the consensus/implementation process
<Zakim> MichaelC, you wanted to say I have no concern with separate doc; just worry about clear complementarity; and need to know how it will get through CR and to mention controlled
Michael: a separate doc is not a
problem, but there should be a clear rel between the multiple
docs
... we need to have a larger discussion about what
implementation means
rich: if you don't need the WG to
do mappings, great. I would prefer not to look at any
values.
... You are not the only group that wants to use this for other
things
... This is a discussion to have with TAG
Markus: DPUB-ARIA is not bound to
ARIA 1.1, correct?
... for strategic reasons, we can delay TR for DPUB-ARIA
Michael: Let's come up phased plan for discussion with larger group
next meeting 6 July
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: Tzviya Inferring Scribes: Tzviya WARNING: No "Topic:" lines found. Present: ivan Tzviya Janina mgylling Rich MichaelC Got date from IRC log name: 30 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/30-dpub-aria-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]