scribenick mgylling

<tzviya> scribenick: mgylling

<tzviya> MG: 2-page spread with an image or table that goes across two "pages" in PDF or EPUB. PDF has a method of connecting these for AT. Is there a method for doing this in ARIA using URI (as opposed to ID-Ref)?

tzviya: we seem to be having some sound issues
... email exchange with Joanie last night re the concept of a page, we may suggest that this is something ARIA should take up for ARIA 2

… we should talk to Joanie about where this is headed

markus: ok

tzviya: we will not meet next week
... any burning issues for TPAC F2F?

… items I thought we wanted to discuss: comments on extended description analysis, the ongoing work in web components, rel vs role

Janina: for rel vs role, we need to specify the use cases and requirements as detailed as we can, from both COGA and DPUB

… that you know where you are going before following a link, and that we support multiple markup languages

… re cross-document flow, I recall doing something about this in ODF, so the issue is familiar to some of us

tzviya: Other suggestions for the TPAC F2F?
... who should we have in the room at TPAC?

Janina: Charles McCathie Neville should be part of the conversation

… I’ll try to make sure that happens

tzviya: I believe one of his groups meets at the same time, so may be hard to schedule
... janina suggests we put together our requirements for rel and role, should we do that now?

ivan: why does the rel vs role come up now?

mgylling: because ARIA hasnt dealt with link natures before

janina: we want it to work in SVG as well as HTML

… there are not only requirements from DPUB but also COGA

<tzviya> See comments on GitHub https://github.com/w3c/aria/issues/96

ivan: my problem with rel is this whole story of extension and the microformats wiki page, I dont know if this whole thing works

… that being said, I talked with Charles about very briefly yesterday, he thinks the whole issue of extension in general should be addressed again

tzviya: it seems that the ownership of the wiki has just shifted

JF: I just wanted to say that the wiki is a gathering place for the various rel values, they all point back to an external spec somewhere else

<tzviya> https://lists.w3.org/Archives/Public/public-dpub-aria/2015Oct/0044.html about ownership of wiki

… there’s lots of people that use the rel value, and document it in their own space

… so there’s no reason why that tradition can’t continue

tzviya: it sounds like this group could define the terms, and then point to it from the wiki

JF: there was a comment that mentioned “as long as it works”, and thats part of the question: what exactly do you mean by “works”

… does it solve your use cases?

tzviya: one of Rich´s concerns is that AT does not make use of this attribute at this time

… but thats not an issue for the DPUB group to solve

JF: a new attribute wouldnt be recognized by AT at this point either

… you want a finite list of taxonomy terms

Matt: the universality question, Rich’s issue that rel is not in SVG, if it doesnt work in SVG then what do you do?

ivan: I think I agree with the fact that the main issue here is, once we have the terminology, the question is if some language has an attribute that can be used for those terms. A link in SVG is in the xlink namespace. The xlink spec has xlink:type that has the same purpose as HTML’s rel attribute

<JF> +1 to Ivan's point

JF: Ivan you hit the nail on the head. If SVG doesnt support rel today, we dont think that that’s a hugely different problem, either add it or use xlink:type

tzviya: [gives summary to Rich]

rich: one question to start with: I was told that you would apply it to anchor tag, is that right?

tzviya: yes, anchors or links

janina: and the ability to return

<JF> <a>, <link>, the almost forgotten <area>

tzviya: if you are searching and you land in a glossary, you want to be able to get to where the term is used

rich: next question: would you never have a situation in digital authoring, where someone put a div instead, and use that with JS to make it look like a link (this is why we had a link role in web pages)?

tzviya: taking a step back, what we are looking for is not a solution on these specific items but a general position from ARIA on rel vs new attribute

rich: from my perspective, whats important, you want something that’s cross cutting, meet the needs of DPUB but also interoperable with AT, the one thing I dont know, if you use either anchor or link and annotate with rel, then rel is not mapped to platform accessibility APIs

… you would have to do some additional work to map the rel attribute to AT APIs

<JF> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

… the problem is that then you have a whole sequence of values at the wiki

… so thats a big long list to shovel to AT

… you can do it either way

<Zakim> JF, you wanted to say that I think this is a weak argument, that not being able to add it to <button> is possibly more problematic

JF: the work of mapping to AT APIs, whether you rel or a new attribute, the work is about the same

… in terms of pollution, in the wiki there are two groups that provides prefixed terms, owner.value

JF: it is well supported by search engines, SEO benefit

ivan: two comments: process of rel registration, the dcmi terms and openid terms were in fact retrofitted into the microformats wiki

… rich, they way you said this is that its up DPUB to decide what they want, but I dont think that this is exclusively a DPUB issue, so I am not sure that presenting it as our responsibility is fair, the very same question of annotating links may and probably will come up in future ARIA vocab modules. So whether we use rel or not is a decision to be taken by ARIA WG.

scribe: they very pragmatic view in DPUB is: which ever works and is accepted

<Zakim> tzviya, you wanted to say that if we define the list of rel within the DPUB ARIA module, can we then include in DPUB AAM?

… that AT doesnt recognize it today doesnt mean that it won’t do it tomorrow

rich: in terms of just providing the metadata for publishing, if you only need anchor and link you’re good, but API mapping issues remain

tzviya: could we include the list of rel values in the DPUB ARIA module, and DPUB Mappings doc?

+1 on tha idea

rich: problem is that HTML itself doesnt have a mapping, there’s really no restrictions in what you put in that space, we cannot define mappings for just some of them

… I would not think its appropriate for DPUB AAM to do that

… you can’t just define that values you have

ivan: but what the HTML specification says, defines a small set and then points to wiki. What is also true is that the way the wiki page is set up that it refers back to the spec, so I think its OK if ARIA WG has rel values in some document and then have the wiki point to these

rich: rel is not an ARIA attribute, we would have to agree in HTML Mapping Guide

janina: Im trying to understand how this gets presented

… would all of the registered ones be supported?

rich: I dont think we can do one without the other

JF: I’m curious when you talk about the mapping, really the only mapping would be a label, its almost an accessible description

… if you’ve got a common taxonomy, you’ve got that list

janina: its multiple taxonomies

rich: the final issue: we dont have a rel attribute in SVG

janina: there’s xlink:type

ivan: we have to figure out where SVG is going with xlink

tzviya: we clearly have not made any decisions yet, lets take this up at TPAC

… I would like to have in place before then on the DPUB side is requirements, and we would like to know where ARIA stands re link types

rich: the reason I mentioned aria-destination is that the COGA group is looking at similar concepts, but their work is far less along than yours

… we want to lock down ARIA 1.1, if this becomes too big of an issue, it wont make ARIA 1.1

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/takl/talk/
Succeeded: s/tidea/idea/
Succeeded: s/bug/big/
Found ScribeNick: mgylling
Inferring Scribes: mgylling

WARNING: No "Topic:" lines found.

Present: Janina Tzviya JF Markus_Gylling Ivan_Herman Rich_Schwerdtfeger

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 15 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/15-dpub-aria-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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