<scribe> scribe: Romain

<scribe> scribenick: rdeltour

Requirements for ARIA 2.0

avneesh: what have we required in the past, what’s the way forward

mattg: not sure what we want for 2.0

<tzviya> https://github.com/w3c/dpub-aria/issues/8

mattg: we hace issue #8 in GitHub
... are there any pressing, obvious semantics we missed out in 1.0, if so, what are they?
... we had discussion about frontbody and backmatter
... the other question that was raised earlier on (by Leonard?) was how to get to title page
... then also requirements for poetry
... that’s all that came up in open issues for added semantics

<clapierre> Was there any comments against any of the existing vocabulary semantics in the original version?

mattg: those are the open items we have
... also the question of followin on the heels of 1.0, is should our focus be on promoting 1.0 rather than add even more to 1.0?
... maybe deal with errata first, and clean up the spec
... I dunno which direction we want to go

avneesh: we already made the decision in the PWG call that we mainly want an errata
... additional things depend on pressing issues and the timeline

dkaplan3: there's a couple of things/reasons why I don’t think we need to spend time on new terms, maybe not even too much on errata
... one reason is that right now there's no functionality to it
... AT parses it, but RS won't do anything with that
... adding more terms isn’t needed
... the other thing, is we need to take a step back and think about what is DPUB ARIA
... are we trying to recreate TEI?
... a lot of the terms shouldn’t be invisible to anyone not using AT
... maybe not belong to ARIA
... ARIA is for those things which are AT only
... we need to remember that
... maybe semantics should be added, but ARIA by design isn't going to be available by non AT users
... we may be doing bad decisions
... as far as I know there is no plan by RS to implement them
... we are adding semantics to the a11y tree only, people forget that
... every single thing needs only be usable by AT
... our focus on the errata should be brisk

bill_kasdorf: in my work, the very fact that ARIA is only for a11y makes it harder for me to convince publishers to use that markup
... they want thigns to describe structural features
... more of this should be part of HTML
... I’d like that only ebooks are born accessible, but the markup is
... I don’t think we should say that if we're adding things they're only for a11y

tzviya: it's true that ARIA is only used by the a11y tree, but publishers can use it in other ways
... we have to be careful with role and epub:type
... Matt started to write a guide on how to convert epub:type to ARIA roles

<dkaplan3> But the publishers would be working against the ARIA spec if they used it in other ways, tzviya.

<dkaplan3> Which is related to my biggest W3C soapbox.

tzviya: one of the things that cause confusion is wishes to what should exist in HTML vs what is in ARIA
... almost none will get to HTML
... if we want things to go to HTML, we need to open issues to WICG, on discourse

<tzviya> https://discourse.wicg.io/t/proposal-list-head-caption-title/1832

tzviya: for instance what I did for list title and caption title
... few people commented
... if we want to get traction, we need people to comment and contribute
... via the WICG
... explain how we would use them with solid real-world examples, and back them up

avneesh: do we know the timeline for ARIA 2.0?

mattg: errata is important because some things are obvious errors, like in examples themselves
... we based at some point in ARIA 1.1, and things changed (like dl/dt)
... that's why I want to push on getting the errata done quickly
... otherwsie fully agree with Deborah on semantics

<tzviya> DPUB-ARIA 2.0 (or 1.1) FPWD is supposed to publish in Q1 2018. We have a little wiggle room

mattg: but even if it's only for AT, there are important holes that can be filled
... even beyond EPUB and its implementation. it's not just for ebooks
... e.g. in poetry there's a disconnect between what a visual reader can get from layout and what's described by AT
... I understand Bill's perspective too, it would be great to have one attribute for everything
... when we came with DPUB ARIA 1.0, it was the impression of some people that we wanted to introduce semantics through the backdoor
... as Tzviya said, not all need to be solved here

clapierre: some of these issues with semantics is also what we've been struggling over in the personalization TF
... some people said that adding semantics to ARIA is missing the boat of adding to HTML
... we have the same issues

laudrain: we are lucky that we decided to have epub:type mandatory in our publications
... it was in the scope of a11y, but now we realize it isn't used for a11y
... now we benefit from it to map to ARIA roles. It makes it easier for our suppliers
... I understand it's difficult to add semantics to HTML. It lacks semantics, it lacks ambition from publishers to move to more HTML semantics
... in the EPUB ecosystem we have epub:type, which use was positive for us

jasonjgw: one of the question is that if you want to add additional semantics, what's the best solution to add to the web techs?
... ARIA is used for AT, but doesn't prevent other people from using it
... one could use ARIA to control visual aspects of the presentation
... the primary use of ARIA is to be used to inform a11y support
... but doesn't mean it can't be extended
... what are the use for additional information?
... extending HTML itself, web components, etc
... not sure what approach is best in which context, but we have solutions available
... I'm not sure what's the appropriate extension mechanism, we have options on the table, the question is what to use?
... one question is the syntax and the format, the other is the semantics themselves

dkaplan3: I was about to make a proposal
... we're all on the same page
... the proposal is to focus on addressing the errata, not focus on adding terms or getting RS to implement what we have
... close all the open issues

clapierre: Ace produces warnings when there's an epub:type and no matching ARIA role
... it will entice publishers to adding them

avneesh: publishing industry may need more semantics, we may need a CG
... for now, it's a good approach to have an errata on focus more on getting things implemented
... see also how this is recepted in the industry
... the parallel thing is the addition(s) to HTML, which is a long way
... there are complexities that need to be resolved

<tzviya> I am not suggesting a new CG, just adding to https://discourse.wicg.io/c/dpub

avneesh: maybe focus on that in the next call
... we should make a plan for all of us to participate

Silver design meeting

avneesh: George is attending the Silver design workshop, what do you need from our group?

[crickets]

jasonjgw: based on a recent update, my understanding is that the Silver TF conducted various research, looking at the use and challenges enocunted in the use of WCAG
... in particular by interviewing various stakeholders
... they intend to publish their results
... they're looking at a redesign
... important process, a publishing standpoint, represents a backward-incompatible shifth from WCAG 2.0
... rething the fundamentals
... for instance, what EPUB Accessbility says with metadata, not necessarily related to content-level conformance, can be put forward in the consideraitons of the Silver process

avneesh: it's a major design meeting
... we had already linked to the publishing requirements
... we have to discuss with George what he needs specifically from us, maybe via email
... Jason, being an insider in WCAG, any suggestion from you?

jasonjgw: the way in which metadata are treated would be one consideration
... can have other use like specialized website, not necessarily achieving general a11y conformance
... that concept could be considered
... some discussion of having more fine-grained technology-specific requirements, but not sure where that discussion is moving forward
... have a core set of principle + more specific guidelines, for instance a publishing-specific module

AOB?

https://github.com/w3c/html-aria/issues/92#issuecomment-364670701

https://github.com/w3c/html-aria/issues/92#issuecomment-364670701

rdeltour: we should spend time to review ARIA in HTML, which will go to CR soon

avneesh: do we need a call for the errata, haven't we decided what goes in?

tzviya: I think we have, some of it was contingent to ARIA 1.1

mattg: errata is rather straighforward

tzviya: wrt semantics, I have a call with Ivan and Garth, I wonder if this is an a11y concern or one for the larger group

avneesh: right

mattg: the errata is really small, could be done quickly. we didn't do it because we wanted to wait on ARIA 1.1

tzviya: I want to talk to Ivan and Garth first

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Avneesh tzviya dkaplan3 rdeltour clapierre laudrain Bill_Kasdorf mattg g_pellegrino jasonjgw
Found Scribe: Romain
Found ScribeNick: rdeltour

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


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)