<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