Minutes for ARIA/D-Pub Interlock Call on 28 April

Minutes from the ARIA/D-Pub ad hoc interlock teleconference of Tuesday 28
April areprovided below as text, and are available as hypertext at:

http://www.w3.org/2015/04/28-aria-minutes.html


   W3C

                                                                                   - DRAFT -

                                                              Protocols and Formats Working Group Teleconference
                                                                                  28 Apr 2015

   See also: IRC log

Attendees

   Present
          janina, Tzviya, Fred_Esch, Ivan, mgarrish, ShaneM, Rich_Schwerdtfeger, Joanmarie_Diggs, Markus, Michael_Cooper, Joseph_Scheuhammer

   Regrets
   Chair
          RichS

   Scribe
          janina

Contents

     * Topics
     * Summary of Action Items
     _________________________________________________________________________________________________________________________________________________________________

   <trackbot> Date: 28 April 2015

   <scribe> scribe: janina

   rich: Suggest to start looking at what raised issues not yet resolved

   <tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html

   ts: Spent time preparing for this call, prefix is issue
   ... Concerned to understand what an ARIA "module" actually is

   rs: Situations like role "part" will be a problem

   tz: But not resolved before FPWD?

   rs: Don't think so, but others may have other view.

   <tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html#co-evolution

   janina: Noting that early 1.0 implementations burned our spec development -- People are now careful from that experience

   rs: We have a different situation here, but it does explain the careful approach

   <Zakim> jcraig, you wanted to say FPWD is first opportunity to implement. Reluctance to change implemented values was a major drawback.

   jc: Yes, early adoption of properties and role values that weren't best choice, but we were later reluctant to improve because of existing implementations

   <ivan> +1 to put a note in the document

   jc: Even if it stays for FPWD, issues with known problems should be well labeled to avoid implementations

   <mgylling> +1 to put notes in the document for all props with issues

   ts: Certainly OK with adding notes, but have a proposal ...

   mg: Started with Shane's email comments ...
   ... Struck by RDFA comments, lack of same flexibility, i.e. global

   <ShaneM> Note that the Role Attribute Recommendation ALREADY supports @vocab as a way of changing the default vocabulary for @role

   mg: Seems rdfa considered multiiple vocabs

   <tzviya> https://lists.w3.org/Archives/Member/w3c-wai-pf/2015AprJun/0031.html

   <ShaneM> ARIA doesn't necessarily embrace this presently

   mg: The rdfa approach would be very helpful for us
   ... q becomes is it a good idea to pack things into a single vocab
   ... concerned with maintanance

   rs: Unfortunately, will be pulling semantics for tests, drawings, etc., etc., and all that will end up in books
   ... And we have no way to switch vocabs on the fly
   ... What happens to an svg drawing in the middle of a book? Etc.

   mg: This an age-old problem now ...
   ... But declaring a default then using the available mechanism to declare additional should help
   ... If PF will expand and involve other content domains, can there really be one list?

   ts: Just want to note that we believe there are existing roles that we believe will be more generally useful -- without prefix,

   sm: Don't believe any AT's support vocab switch, but the spec does support

   <clown> http://www.w3.org/WAI/PF/role-attribute/

   sm: Vocab is not the solution, vocab is good to use, but the switch won't solve the problem
   ... Please remember we're trying to expose meaningful semantics for a11y

   ivan: Noting how it works in rdfa, vocab attrib on anything, so ...
   ... think it should be different for aria
   ... we think there are values that should be global
   ... suggest working out what's global and what's local to a particular doc
   ... Don't understand why rdfa switch isn't a solution, even if it's not the best solution

   sm: Syntax is well defined, but not for additional name spaces

   <Zakim> jcraig, you wanted to say that potentially solves parsing confusion, but not author confusion.

   sm: Don't know how to say XX is an ARIA term, not a generic

   jc: My main concern is author confusion
   ... Unlikely a definitve source of values

   s/definite/definitive/

   jc: Agree we will find globally useful terms

   <jcraig> http://www.w3.org/TR/wai-aria-1.1/#text

   <jcraig> As with any ARIA 1.1 role, authors may provide a fallback ARIA 1.0 role.

   jc: Future of ARIA was set up to have chain of roles

   <jcraig> <p>I <span role="text img" aria-label="love">♥</span> New York.</p>

   <ShaneM> From an ontology perspective, if we are creating independent vocabularies, it would be MUCH better to use dpub:foo than dpub-foo. Then then semantics are
   well understood

   jc: Best path is to start with prefix, and wait for review and adoption to promote some to generic
   ... no risk of name trampling this way

   <ShaneM> note that @prefix is part of HTML 5 and allows definition of the mappings from a prefix to a URI

   <ShaneM> so follow your nose interpretation of terms comes for free

   rs: Q: Won't the mark up for epub be auto-generated? by author tools? not by hand?

   mg: Tried over the past years, but hasn't succeeded so far

   jc: Can you explain the concern?

   mg: People do still hand code
   ... It's a hard sell in the epub world, these are people who probably care more than anyone about semantics--that's historic to publishing
   ... Concerned that starting with prefix, but after sometime transitioning to a generic role would be a problem as well
   ... We would be stuck actually

   <jcraig> fallback role set up to support="chapter pub-chapter"

   <jcraig> role="chapter pub-chapter"

   <ShaneM> note that role="chapter pub:chapter" is also supported

   <richardschwerdtfeger> :-P

   jc: At least in webkit, adding prefixes is trivial, so not as concerned about prefix petrification

   <ShaneM> and prefix="pub: http://www.example.org/myvocab#"

   jc: notes that role=none for role=presentation was one line of code in webkit

   ts: hyphen is valid?

   rs: yes

   ts: our goal is wide adoption, we had problem with takeup in epub

   <jcraig> role="pub-abstract summary"

   rs: Noting we're considering a draft ....
   ... What if we put the prefix in for fpwd, add a note, then go discuss with pubs
   ... This would actually lock in semantics, no one could take them elsewhere

   ts: Noting current participants are pub representatives, that's why we're here

   rs: Still trying to understand why it's a problem
   ... Recall the concern for validation, but we can achieve that

   <Zakim> shaneM, you wanted to explain @prefix is part of HTML 5 and allows definition of the mappings from a prefix to a URI

   rs: Noting our history arguing with HTML over the delimiter -- half a year over hyphen vs colon

   sm: Noting again that machine understanding for semantics is well defined by rdfa

   ivan: Skeptical that people will use only authoring tools, it hasn't yet happened, still have to go into code from time to time
   ... If someone can pull this off for HTML, o0utstanding
   ... Our problem is that publishers would have difficulty using prefix

   <Zakim> ShaneM, you wanted to talk about why using @vocab is not the solution

   sm: Today ARIA spec doesn't indicate that vocab controls -- a substantial problem because we already have many implementations

   ivan: which is why I don't like vocab, it's not the same as rdfa

   <ShaneM> so its @role-vocab?

   ivan: believe we're offering roles that will work for many communities

   <ShaneM> defines the URI prefix for naked terms used in attribute values

   ivan: role vocab would define a dom subtree, where we could use terms without prefix

   <Zakim> jcraig, you wanted to mention that the role parsing in UAs is a flat list, so the dpub roles could be used outside the epub context... just in regular web
   apps and to say

   jc: Don't want to digress but understand xh+rdfa complaint was runtime access to on line

   ivan: not the case here

   <ShaneM> XHTML2 never required that sort of external resource retrieval... but whatever

   ivan: I want to keep away from rdfa

   ian: we're defining a module that makes the author's life simpler

   rs: so if we put vocab at beginning, start role=chapter, then mid point we put an svg drawing
   ... what happens?

   <ShaneM> AND what gets passed to the AT

   rs: Note we're also talking attribs, not just roles

   <ShaneM> remember that a role name is not just a string of characters. it conveys rich semantic information that influences the current element and its children!

   ivan: is it much more complex for the author to make those switches?

   <jcraig> q later ShaneM

   ivan: we know we don't have a 100% solution, we're deciding among suboptimal solutions

   <Zakim> jcraig, you wanted to mention that the role parsing in UAs is a flat list, so the dpub roles could be used outside the epub context... just in regular web
   apps and to say

   jc: noting that javascript is often hand coded
   ... all roles are parsed as in a flat list, anyone can use any role in any context

   <ShaneM> technically role="main" today should be passed to the AT as http://www.w3.org/1999/xhtml/vocab#main

   <ShaneM> I know that it is not... but it should have been.

   <Zakim> ShaneM, you wanted to ask what happens to references to core roles? and to and to ask what happens to references to core roles? and to and to

   <Zakim> later, you wanted to ask what happens to references to core roles? and to and to

   sm: implication that nonvocab specific generic terms will still be available ??
   ... role=baegel main
   ... need at that knows "this is the main content"
   ... just don't understand how it mapps out

   <ShaneM> +1

   <ShaneM> URIs are SUCH a good way of disambiguating terms

   janina: suggesting we're pushing user agents to be smarter with domain specific semantics

   rs: Clearly we have more discussion, but what gets us to an fpwd?

   <jcraig> prefix placeholder is the only suggestions I've heard that will satisfy me for a FPWD

   <ShaneM> +1 to adding notes about role values that are of concern

   ivan: Make the situation clear, publish as is but note the prefix concern in a global way
   ... add both solutions discussed, and ask for comments
   ... clearly note this needs solution before the document can progress

   <ShaneM> sorry _ uave to leave

   jd: like most of the proposed roles, suggest putting a subset of these as fpwd

   ivan: yes because i believe mosttterms are indeed generic, but no because we need to vet the problem terms and approaches

   <Zakim> jcraig, you wanted to say if you publish without profixes, you need a clear RFC-2119 "User Agents MUST NOT implement this FPWD"

   jc: suggest a clear rfc2119 "MUST NOT" implement
   ... Could also take the generally agreed ones directly into aria-1.1

   <richardschwerdtfeger> we are looking to get into cr later this year

   ts: gets fpwd, but what to do with the problem terms isn't vetted

   <richardschwerdtfeger> toward year end

   rs: also discussion in pf of how modules work

   jc: don't understand why publishing is waiting on this?

   ts: not everything is epub

   rs: the role attrib will validate, which helps pub

   <richardschwerdtfeger> aria-value=

   <richardschwerdtfeger> “pub”

   ivan: likes rs's idea -- we're trying to get proposals

Summary of Action Items

   [End of minutes]
     _________________________________________________________________________________________________________________________________________________________________

Found Scribe: janina
Present: janina Tzviya Fred_Esch Ivan mgarrish ShaneM Rich_Schwerdtfeger Joanmarie_Diggs Markus Michael_Cooper Joseph_Scheuhammer
Found Date: 28 Apr 2015

-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Tuesday, 28 April 2015 18:17:26 UTC