<scribe> scribe: MarkMccarthy

[introductions for Greta Krafsig- welcome!]

MarkMccarthy: Greta joins us from the Washington Post, and hopes to make their sites and properties more accessible
... She comes to the a11y community from when she was 13 years old, made a game that many blind people played at the time
... Greta's game that got her started in accessibility: http://www.whiteoakstables.net

New Issue Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2020-05-07+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

<jamesn> https://github.com/w3c/aria/pull/1269

jamesn: one approving review for PR 1269, need two more reviews

<jamesn> <p class="note">It is recommended that authors key visibility of elements off this attribute, rather than change visibility and separately update this <a>property</a>. <abbr title="Cascading Style Sheets">CSS</abbr> 2 introduced a way to <cite><a href="https://www.w3.org/TR/css3-selectors/#attribute-selectors">select on attribute values</a></cite> ([[CSS3-SELECTORS]]). The following <abbr title="Cascading Style Sheets">CSS</abbr> declaration makes

<jamesn> content visible unless the <sref>aria-hidden</sref> attribute is <code>true</code>; scripts need only update the <span>value</span> of this attribute to change visibility:</p>

<jamesn> <pre class="example highlight lang-css">[aria-hidden="true"] { visibility: hidden; }</pre>

carmacleod: i dont think this note is appropriate, just want to remove it

jamesn: i agree, its not very useful
... if those reviews can be done quick i'll get it merged

carmacleod: thanks!

jamesn: 1264, consider camelCasing for markup languages
... comment on slack was raised that this can be confusing for blind/lv devs, camel casing would help with pronunciation
... 1.3, discuss later?

sina: yeah

jamesn: worth discussing, but might be hard to do

New PR Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Apr+repo%3Aw3c%2Faria+created%3A%3E%3D2020-05-07+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

jamesn: i think we covered all of these already

<jamesn> https://github.com/w3c/aria/pull/1261

jamesn: covered the first one, 1261 is waiting on me
... aaronlev you're signed up on this, timeframe?

aaron: in the next week

jamesn: great!
... 1260, needs aaron and myself, but should be simpler

<jamesn> https://github.com/w3c/aria/pull/1260

aaron: got it

Remaining ARIA 1.2 Issues

<jamesn> https://github.com/w3c/aria/milestone/10

jamesn: already covered two of these
... 828?

joanie: looks like only a couple not merged, i'll look

jamesn: 1058?

carmacleod: theres a PR for this

jcraig: I'll take a look too

jamesn: 1151, jongund's PR for aria-owns

<jamesn> https://github.com/w3c/aria/pull/1224

Matt_King_: i needed this done earlier, i'm on it

jamesn: have your issues been resolved jcraig?
... reviews haven't been done yet, need this finished so we can wrap up

Matt_King_: i should be able to finish this today

jamesn: there's a merge conflict, jongund can you check on it?

carmacleod: does alex need to be on this?

joanie: i'll look into it, see what i can do

jamesn: if 1.2 reviewers could please prioritize, that'd be great
... 1150, last week we agreed to postpone to 1.3
... i'll add a link to the minutes

carmacleod: did you see the email i sent? catch-22 in this list of issues

<Jemma> https://github.com/w3c/aria/issues/1150#issuecomment-618610302

carmacleod: 1150 says wait for 1162, 1162 says wait for 1033, 1033 was moved to 1.3. so we'll need to ignore something and partially fix 1150?

jamesn: 1150 only came up on this list because i didn't move it until just now

carmacleod: nevermind then!

Create property for repeated content

<Jemma> https://github.com/w3c/aria/issues/1044

jamesn: just want to know if we have some updates on this and if it needs to be on the agenda

aaron: we decided we'd go with running page header and footer roles, have doc- prefix. what we'd like in the long term is the aria group take over dpub
... would also like to upload a PR to dpub-aria, a draft PR to have people look at it, as a placeholder for comments etc. Then we'll have some footing if we take over

jamesn: are you going to take the lead on this?

aaron: i'd love to but have been buried, would love help

jamesn: if anyone wants to help with dpub-aria, feel free to jump in

jcraig: i might be able to help
... yeah, assign me jamesn, i can at least leave some comments

aaron: jamesn, what steps do we need to take over the project?

jamesn: i think they're happy to have someone take over, so just red tape

joanie: i'd have to go back and look at Tzviya's email, but yeah, just some process

<Jemma> https://github.com/w3c/aria/issues/1044

jamesn: aaron can you leave some comments for jcraig?

aaron: yep

<pkra> :)

pkra: happy to help!

New Naming Methods - Discussion

jamesn: came up with these new methods when doing role parity

Matt_King_: is there a single issue to track this?

jamesn: no
... in 1.2 we have name from author, contents, and prohibited

<jamesn> legend: name comes from the text value of the first descendant element node with the role of legend. Although "legend" may be allowed in addition to "author" in some roles, "legend" is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm.

<jamesn> encapsulation: name comes from the text value of the element node with role label that is the closest ancestor. Although "encapsulation" may be allowed in addition to "author" and "contents" in some roles, "encapsulation" is used only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm.

jamesn: propose new concepts; name from encapsulation and legend [see details above]

<carmacleod> https://github.com/w3c/aria/issues/899#issuecomment-487607333

Matt_King_: was legend also meant to capture caption? i don't remember

jamesn: there's a caption role in 1.2
... conceptually, we're just talking something named by ancestor or descendent
... i struggle over the additional complexity we're adding
... would like an open discussion over should we do this? benefits for authors? users?

<carmacleod> https://w3c.github.io/aria/#namefromencapsulation

Matt_King_: most important question to ask, for me, is whether or not there's need for this in HTML parity space?
... if we're going to have these roles (label, caption, legend, etc.) in aria, wouldn't this be neecessary to support role parity?
... if there is -not- an absolute need, then we can answer the other questions

jongund: i think authors will do this, they're already doing it. so it's a bit undefined what browsers might do with it or if they'll do it. especially if it's about HTML parity; it might cause a disconnect for authors "why's it work here and not there?"

jamesn: back to Matt's question - maybe i'm seeing role parity as the ability to do everything the need to do, from an a11y POV
... if you're creating a web component that needs labelling from encapsulation, I'm not sure this way is the best way to do that
... i don't see the benefit of this over aria-labelledby etc.
... or the HTML label element can do a lot of this

Matt_King_: can't use an HTML label on a custom select made from a div

jamesn: correct

Matt_King_: using aria-labelledby on that is also not equivalent. that'd have to point to an element that contians just the label

jamesn: just tells me this will be even more complex, then

Matt_King_: not sure about that, that might be a thought for aaron
... same logic for HTML label
... if all this holds, would an HTML label work around an ARIA Combobox?

jongund: yes

<carmacleod> Here's the ARIA label role: https://w3c.github.io/aria/#label

jongund: i think i want to mirror what Matt said, we can use the label element now, it's standard HTML
... if we go through with this, i can use div role=label for encapsulation, vs a plain label. i worry about creating more gotcha's for developers or screen readers
... and i don't want to send people to spec more than necessary
... if we're not gonna do this, take it out

sina: i think this should be included, if we're doing role parity. but i agree with Jon, it'd be terrible to have it and force people to read a nuanced spec
... if you've already taken the time to learn a11y, which already isn't common, forcing another nuanced semantic on top of that might not be fair
... but if a div role=label encapsulates something, it should act like a label

jcraig: this is a complicated issue, but i want to acknowledge the need for encapuslation
... i'm not very up on this issue yet, but i want to look into it. that said, i agree with sina and jon
... it seems useful, value of role parity is there

<Zakim> joanie, you wanted to comment on divs "acting like" labels

joanie: i see both sides, but want to hone in sina's point about divs acting like labels. even if you slap a role on a div, the encapsulated element still needs some work to get it right. there's still -some- gotcha's

carmacleod: that's also true on the HTML side, a label with a for attr, for instance
... is the main driver for questioning this because it'll be difficult to write accname?

jamesn: it's good to question what we've done based on momentum
... and if that creates too much complexity, then maybe we should slow it down or not do it
... if we have to wait, we have the time to do so. and this seems worth discussing

Matt_King_: responding to jcraig - this rabbit hole started when we tried going a little beyond HTML
... like the idea of labelling a dialog with a heading

s/heading / heading, for instance

Matt_King_: it might be helpful to scope this to _first_ discuss the things that exactly mirror HTML in the simplest way
... like using label on a checkbox, combobox, etc.
... after we've done the simple stuff, the maybe go on to complicated things. jamesn it might be helpful to have a meta issue to group discussion and allow ansynchronous comments

jamesn: another way to go is to try and have HTML allow label on more things

<Zakim> jcraig, you wanted to state, technically we have parity in that the functionality to label exists, even if it's not a role per se

jcraig: the exercise for role parity was to allow devs to do in aria what they can do elsewhere
... doesn't necessarily mean we need 1:1 HTML:ARIA roles
... to joanie's comment - yes, adding label wont get the click focus, but it -can- be done with JS
... secondly, we could, as part of parity, is say these means and functionality exist via other things, like aria-labelledby

aaron: i hugely agree with jongund and want to get rid of gotchas. even if we do that, we might have the same group of gotchas. i feel a bit pinched, we have nowhere near enough a11y engineers to solve all these problems
... in other words, if this is a big issue, we've come really far and i agree generally. but this doesn't reduce gotcha's, like joanie said.

jcraig: it doesn't solve the need to make things possible, necessarily. web devs can already label things.... and adding the label role doesn't help the web driver testability problem either.

aaron: right, it's not adding capability or improving anything, necessarily, which are noble goals, and that all takes lots of engineering time

Matt_King_: true. thinking of the amount of time this would take versus other things we could do, it's important to prioritize things

jamesn: good comments everyone, thank you very much
... i'll open an issue for discussion and put these minutes in there.

Matt_King_: as an aside, it might be cool to have a place where we can stack up big issues like this, meta issues, etc.

jamesn: thanks very much everyone, please check on your reviews!

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)

Succeeded: s/for Greta /for Greta Krafsig/
Succeeded: s/descenden/descendent/
Succeeded: s/element/role/
FAILED: s/heading / heading, for instance/
Succeeded: s/might be /as an aside, it might be /
Succeeded: s/make things possible, necessarily/make things possible, necessarily. web devs can already label things.... and adding the label role doesn't help the web driver testability problem either./
Present: pkra MarkMccarthy Joanmarie_Diggs Jemma jamesn jcraig jongund BryanGaraventa StefanSchnabel BGaraventa harris aaronlev Greta Matt_King_ michael carmacleod
Found Scribe: MarkMccarthy
Inferring ScribeNick: MarkMccarthy

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