<Jemma> https://github.com/w3c/aria-practices/wiki/March-31%2C-2020-Meeting
<scribe> scribe: MarkMccarthy
mck: lots of people switching to zoom - do people want to switch?
MarkMccarthy: i like zoom's audio better
CurtBellew: +1
mck: okay, Jemma, can you talk to Michael?
Jemma: yep
mck: we'll skip first two agendums, since we have no updates
https://github.com/w3c/aria-practices/pull/1356
mck: we don't have a review checklist on here yet. we need code, vis design, and a11y - is that right jon?
<jongund_> my mike is not working
<jongund_> I am going to reconnect
siri: I have a question in the meantime - high contrast falls under what SC?
<Jemma> Siri, https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
jongund_: can we also talk about 1358 too?
mck: yes.
... so 1356 wasn't just a CSS change, all the PNGs were changed
too right?
jongund_: let me look
jongund: oh sobasically, i reorganized the directory to be more like our others
mck: and i see menubar is now named to editor menubar
jongund: basically, yeah
<Jemma> https://github.com/w3c/aria-practices/pull/1359
mck: if we merge editor menubar first, for instance, that won't create conflicts with navigation - they'll just be duplicate files until we merge the other?
jongund: yep
mck: in terms of reviews - need folx to look at this on HCM so an a11y review, a code review...
jongund: overall theres few changes to the HTML itself. probably the same people could review the nav menubar at the same time, they're very similar
mck: let's set em up right now
and get some people assigned.
... who wants to check HCM compatibility?
Jemma: for editor or navigation?
mck: both
Jemma: I checked HCM already and it looks okay, but i'll take that regardless
mck: code review? our usuals aren't here today, so i'll reach out to them. maybe simon
jongund: okay
mck: so - i'll set up the reviews and get reviewers, simon and jemma should be sufficient, in addition to myself
<Jemma> https://github.com/w3c/aria-practices/pull/1356#issuecomment-601379818
Jemma: is 1358 related to this?
jongund: yes, to get regression tests to work there's some funky behavior
jongund: everything's fine in the browser, but the code is funky. it's affecting everything i've done in the last couple weeks
mck: 1350 is kind of the root of this, right?
github: https://github.com/w3c/aria-practices/issues/1358
<Jemma> KeyboardEvent.keyCode Deprecated #1350
jongund: that's not a problem, we can move to <key>. the problem seems to be selenium
Jemma: maybe valerie could help us, since she helped with the regression testing framework
mck: i put 1358 in simon's queue
for infrastructure
... whats unclear is what the solution is.
... was also wondering - some things in 1350...would it make
sense to have a utility class or utils script to define some of
this? so it's only in one place, then reuse from there?
jongund: i don't think we really
need a utility. the main issue with <key> is that edge
used different constants
... and now that they're moving to chrome, things might be
different. i don't think a utility would help. all the new
event handlers are a lot more streamlined
... and everything is a bit more literal and eaiser to
read
... the previous examples just used numerical constants, so
this is easier. but the space issue is frustrating, especially
becuase it's -just- the regression tests that are having an
issue.
... maybe we just let those tests fail for now, and rewrite the
code correctly.
mck: so right now, this affects 4
PRs, right?
... so if we let them fail and allow these things to be
merge-able, we can leave 1358 open and for each example marked
as failing, add it as a checklist in 1358
jongund: that might work
mck: i'd be alright with that, to help us keep track
jongund: and to keep track of new issues as they arise
mck: yeah. but then we can keep
track and whoever takes up 1358 will have a list to work off
of
... or maybe a new version of Selenium will fix it who
knows
jongund: right, maybe it's just an obscure bug
mck: okay, so let's use that plan for now.
<Jemma> https://github.com/w3c/aria-practices/pull/1279
mck: just need a couple minutes. there's a TODO in the issue, the most recent comment has it
<Jemma> Update table in section 8.1 to match table in Jon's comment above
<Jemma> Edit text for min/max/now in sections 8.3 through 8.7 where the text does not match the requirements in the table.
<Jemma> In the meter section (8.3), add a sentence with a link to the meter pattern similar to the sentence in the slider section that links to the slider pattern.
<Jemma> In the spin button section (8.7), add a sentence with a link to the spin button pattern similar to the sentence in the slider section that links to the slider pattern.
mck: thanks to Jon for coming up
with this. just needs implementing in the branch.
... some editorial work needed too, need some links to meter
and spinbutton patterns
Jemma: i can do it if you'll review later
mck: cool - that's all we need. can you do that this week?
Jemma: yep!
... close to being done, so definitely
mck: in the PR i included a link to a preview
MarkMccarthy: link is above
group: [reading through some of the text]
mck: problematic bit is we don't
know what to say for listitem
... basically - is what's being presented in section 8.2
realistic?
Jemma: any thoughts BGaraventa
jongund: unless it's a fragment of a larger list, why would we do this?
BGaraventa: like sublists?
jongund: no, like this is a deeper list --
siri: it has aria-level 2, should it be 1? do we need to keep aria-levels on an OL?
jongund: maybe these aren't the
best examples, don't want to confuse people if we can help
it
... maybe using div and listitem. do browsers compute the
levels with that combination?
mck: not sure if it's required
that they do but i think they consistently do
... usually, screen readers don't reveal the depth to you, but
maybe the nesting level in the beginning of the
announcement
... it's not on the LI it's on the UL
... i wonder if this allows you to create a nested list without
a nested parent list element?
... like three list items with the same parent, but different
levels
siri: that's the last example they had; i think it's really confusing to have sibling LIs but different levels
CurtBellew: +1
siri: i also won't usually recommend going more than 2 levels, and screen readers won't group by level, they'll just read total LIs
mck: right it's not read like a
tree or interactive listitem
... seems odd that screen readers can't/won't query that info,
but you can nest as far as info architecture requires
... bigger question is, what do we say about using aria-level
on listitems? it's supported but...no practical examples of its
use
... that doesn't seem like good guidance. we could recommend
people not do it, but that also would need a rationale
... only circumstance is a big list that doesn't fit in the DOM
and how AT keeps track of the nesting. never seen that in a
static list
Jemma: spec says in RARE scenarios; problem is we're trying to find those rare scenarios, rather than practical uses. or, if the rare scenarios are indeed rare/theoretical, do we really need it?
mck: +1. if it's truly a rare scenario.... is it so rare we can't come up with a realistic one to share?
Jemma: that's what i'm saying!
mck: that's how it feels to me
jongund: the only examples is if you're creating list items out of divs, but that's about it
CurtBellew: but then wouldn't you put it on the UL?
mck: well, if the roles are applied correctly, browsers should calc it appropriately
CurtBellew: i see
jongund: only place is in a tree widget or something...
mck: but that's treeitem right?
jongund: i know - so maybe it shouldn't be allowed on listitem
Jemma: [chuckles]
mck: well, a situation where a portion of the list scrolls in and out... only a piece of it is in the DOM...
Jemma: last time, one of CSUN presentations by Microsoft is proposing something to address that... but anyway
mck: BGaraventa have you encountered any real life scenarios for this?
BGaraventa: not personally, which isn't to say there isn't one or a reason, but I have no direct experience
jongund: if we don't have a good example, it's probably not a good use of time - we have lots of other problems we -can- solve. maybe it's just an artifact of listitem
CurtBellew: an example with divs?
jongund: well, it's a matter of if browsers need to calc it or just advisory
CurtBellew: makes sense
jongund: and mck you said the level doesn't play into the UX of lists, really, right?
mck: well, with a partial list. say the second half of a structure with two levels of nesting - if you didn't present the proper level of nesting...
jongund: so then how about this - if a list is only partially represented AND it's important, then this can be used. i can rewrite this section to match up with that
Jemma: +1
mck: something where there's a
couple levels and the first portion is cut off so the first
thing you come to is a list item at the second level of
nesting.
... what's weird to me - if the whole thing isn't in the DOM,
would you encounter a list item without a parent list? or an
invalid list structure?
... becuase that results in -other- problems
github: https://github.com/w3c/aria-practices/pull/1109
BGaraventa: if you're gonna
directly add a list item into something, the browser will auto
calc the number of children when a node is added or removed,
always at the same level.
... so i can't really see a logical reason for different
levels
mck: just trying to picture the incomplete DOM thing. you'd need a whole list anyway, so a browser would calc the correct level...
BGaraventa: and the a11y tree isn't computed after the DOM is done
mck: so now i'm thinking about raising an issue with aria about not having this on LI
BGaraventa: +1
siri: +1
CurtBellew: +1
<Jemma> +1
mck: okay, so i'll raise that issue. this seems impossible.
<Jemma> no aria level for li!
mck: so if there's consensus,
maybe we'll leave this out.
... or 1.3 if nothing else
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/so /oh so/ Succeeded: s/the framework/the regression testing framework/ Succeeded: s/streamlines/streamlined/ Succeeded: s/listiem/listitem/ Succeeded: s/interactice/interactive/ Succeeded: s/sarah said microsoft/one of CSUN presentations by Microsoft/ Present: mck Jemma jongund CurtBellew MarkMccarthy Bryan_Garaventa siri Regrets: Sarah_Higley JamesNurthen ZoeBijl Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy Agenda: https://github.com/w3c/aria-practices/wiki/March-31%2C-2020-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.)[End of scribe.perl diagnostic output]