<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
<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
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
<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!
<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!
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.)[End of scribe.perl diagnostic output]