W3C

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

13 Dec 2018

Attendees

Present
jamesn, janina, HarrisSchneiderman, aaronlev, pkra, melanierichards, Jemma, MichaelC, Stefan, Joanmarie_Diggs, jongund
Regrets
CarolynMacLeod, MattKing, BryanGaraventa, MarkMcCarthy, IrfanAli
Chair
JamesNurthen
Scribe
melanierichards

Contents


<pkra> :)

<pkra> thanks.

New Issue Traige

<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2018-11-29+

jamesn: #863, Michael can I assign to you?

MichaelC: yes

[jamesn assigns some issues to Harris and Melanie based on prior discussions]

jamesn: #849 is the last one. We've actually already dealt with this two weeks ago, so we're done with ARIA issues
... putting a 1.2 milestone on https://github.com/w3c/core-aam/issues/39

<jamesn> https://github.com/w3c/core-aam/issues/39

jamesn: any issues with that?

stefan: question regarding default required things, especially aria-level. We are already encountering in a tool, where we define a role with no aria-level set, how do these tools handle the default fallback handled here? What should tools do?

jamesn: the idea is that we are clarifying that if something is required, the author should specify it. The default is a "fallback technique". The tool should flag it as an error.
... ...as an error if the author has not set the required value

stefan: it would be great to have a lookup table of all the required stuff for cross-checking
... required for author means it remains required

jamesn: correct

stefan: guidance seems a little different for author vs browser

jamesn: browser does a lot of correcting, but we should be stricter on author. example of invalid HTML that gets repaired in browser

Edge & Chromium

jamesn: just want to look at impact on ARIA specs

melanierichards: working with Chromium to stand up UIA there

jamesn: don't see much impact, maybe just a name change for the UIA column (Edge + UIA perhaps becomes Chromium + UIA)

joanie: we still will have a user agent that implements UIA. is it correct to state Microsoft's plan is to work with Chrome and other devs to fully flesh out UIA in Chromium?

melanierichards: correct

joanie: we already talked about splitting up AAMs on a per-platform basis, so if there's any delay, they'll just go to REC when ready

jamesn: there's a slight impact on ARIA spec, 2 implementations for each feature. So we couldn't rely on two Chromium based browsers for that criteria

joanie: correct
... Chromium already implements other accessibility APIs. For ARIA specs, we have always called that one implementation instead of 3
... so we're basically down to 3 user agents for the ARIA spec

jamesn: so we need 2/3 instead of 3/4

Aaron: see how this goes and if users are getting hurt, we can re-evaluate (talked about some alternative ideas for process)

jamesn: would have to re-charter for that

aaron: [some concerns around fewer implementations]

joanie: ARIA WG members can always submit patches if we feel strongly about getting something to REC

Annotations

<jamesn> https://github.com/w3c/aria/issues/749

aaron: the last thing that happened w/ annotations was, we had posted a draft proposal on the wiki. there were concerns from the web annotations data model team. They wanted to make sure it synced up with their stuff. We needed to show how info in their model could be mapped to ARIA. Talked to Tzviya, bigbluehat, and MattKing. I've updated the draft proposal

<jamesn> https://github.com/w3c/aria/wiki/ARIA-annotations-draft-proposal

aaron: the update is in issue 749, wanted to present that to the group
... small things, the big thing was terminology. One of them was annotation type, we changed to annotation purpose. We had a high-level description of the relationship between the two specs
... also how you might mark up the annotation model with HTML and ARIA
... "comment" type moved to "commentary" to make it clearer it could be multiple comments

jamesn: I thought we moved to annotation based roles?

aaron: yeah. role goes on annotation body (thing that holds the comments for example)
... some TBD notations on things I felt unresolved

jamesn: do you think you need resolution for them on a v1?

aaronlev: MattKing definitely wanted annotation- prepended on the role, I wasn't sure about that. But we'd need to discuss as a group on how to group these roles together

[seems like people need more time to read, we'll all read through it and add comments]

jamesn: I'm struggling with a bunch of new roles that seem tightly related

aaronlev: I think we might have resolved that last time

jamesn: I'll read back through the issue and see what the coverage was on that

aaronlev: if people could think about anything marked TBD, or anything else they're concerned with, that would be great
... MattKing would prefer that annotation- would be removed (scribe note: sorry, heard the previous statement backwards!)

Prohibit Naming certain roles (#833)

<jamesn> https://github.com/w3c/aria/issues/833

jamesn: proposal to prohibit accessible name via aria-label / aria-labelledby to certain roles
... people didn't want to allow names on certain roles because it was not a useful thing to do
... asked James Teh for comments, he came up with some edge cases where he felt people SHOULD be able to set names. listitem was one, I would certainly not object to removing that if it were the consensus
... also cell, someone might want to override the accessible name

<jamesn> https://github.com/w3c/aria/issues/833#issuecomment-446830597

jamesn: want do we want to do based on these comments?

stefan: the question is, if we allow this, what will the screen reader do?
... does it treat it like a text node inside

aaronlev: if people put a label on something, map it as group?

jamesn: or they could put a role group on it
... if we change this it can be added to validators to not put names on these

aaronlev: we can say, if it happens, they can at least get treated like divs

jamesn: the second one with the role of cell, that seems like the perfect use case for our non-discarded static role. put it on the bold element instead of the cell itself
... if you have a named container that has children, how and where are you going to present that to the user?

stefan: we need to distinguish here that there's possibly an author error if they put a name on a certain role? and then a fallback approach for browsers? or should it not be allowed at all for anyone (authors, browsers)?

jamesn: doesn't work consistently today when people do this .a fallback would be a nice to have in the case where an author does something wrong, I don't see it as a super high priority because validators can pick this up and hopefully get the author to correct it.

<Zakim> joanie, you wanted to propose we start with prohibiting the div/span (html-aam) and generic only. Then we need guidance for authors and screen readers.

joanie: Jamie raises a good point. We do have consensus that we don't want divs and spans and our to-be-created generic role to have names?
... I think we do have consensus there
... maybe we just start with those and see what kind of feedback we get

jamesn: can we add paragraph in those as well?

joanie: maybe get Jamie's feedback on that too

<HarrisSchneiderman> I have to drop off for a dentist appointment

joanie: we need authoring guidance, and even though we don't normally specify it, we need guidance for screen reader developers
... we need authors to do something screen readers expect, and we need to know what the community expects screen readers to do

<joanie> https://github.com/w3c/aria/issues/756

melanierichards: in my experience, devs expect to put a name on any element and hear it read out via any navigation modality. But to Matt King's point, that is maybe not a pleasant end user experience. so even if they do expect it, if we can clearly specify what should be expected, then that will be helpful to influence expectations and get the right user experience

aaronlev: maybe treat it like a group if the name is there

aaron: in cases where there's a name but no role

jamesn: most of our error correction section for UAs specifies a should and not a must. Would you imagine that error correction to be should or a must?

aaronlev: maybe a must

jamesn: I like proposal for Joanie's proposal for div, span, and potentially generic role

joanie: to be clear, if the thing we're talking about doesn't have a role and we want it to map like a group, that's not something this WG covers. That's HTML-AAM

<Zakim> joanie, you wanted to say if there's no role it's not ARIA, but HTML

joanie: for things that have paragraph role and blockquote role, not clear if you want to have those be treated as a group role instead too
... aaron, please CC me if you talk to HTML folks about that (paraphrased)

aaronlev: so we need to have HTML-AAM decide what it should be, so we don't have to decide right now

joanie: right

Role Parity text separation attribute (#699)

jamesn: when we're talking about role parity, we have a generic role. I want to focus on text separation property today. We should probably cover first that people are ok with prohibiting name on this generic role
... if so, we can add it to the current pullrequest
... anyone object?

<pkra> -1

<pkra> or rather: I have a question

pkra: I wanted to ask in the discussion before, I put one example which is something I come across frequently. If I have Unicode from a private user area, then I have to put a label on that
... scientific community really keen on that

jamesn: our current recommendation for this, for something that can't be read: the only recommendation we have currently is image with a label. Of course that would read out "graphic". Rather than using role="generic" and adding the label on that, I would rather reopen role="static" and gather use cases for moving forward to it. I don't understand the previous objections to static

stefan: I remember discussions of having role="text" too. Has this rolled into static discussion?

jamesn: yes, text got rolled into static
... if we were to have such a role, would that solve your use case?

<pkra> +1

pkra: I believe so

jamesn: does that sound better than having name on generic?

pkra: I think so

<pkra> +1

jamesn: I'm going to propose updating PR to prohibit names on generic, and reopen static

joanie: I'll dig around to find the draft for static

<pkra> bye!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/12/13 19:03:00 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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: jamesn janina HarrisSchneiderman aaronlev pkra melanierichards Jemma MichaelC Stefan Joanmarie_Diggs jongund
Regrets: CarolynMacLeod MattKing BryanGaraventa MarkMcCarthy IrfanAli
No ScribeNick specified.  Guessing ScribeNick: melanierichards
Inferring Scribes: melanierichards
Found Date: 13 Dec 2018
People with action items: 

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


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.)


[End of scribe.perl diagnostic output]