<pkra> :)
<pkra> thanks.
<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
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
<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!)
<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
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!
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]