ARIA Authoring Practices Task Force -- 31 Mar 2020

<Jemma> https://github.com/w3c/aria-practices/wiki/March-31%2C-2020-Meeting

<scribe> scribe: MarkMccarthy

Future meeting agendas

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

menubar 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

Space key and Selenium testing framework

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.

Guidance / range related properties

<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

Guidance / aria-level

mck: in the PR i included a link to a preview

https://raw.githack.com/w3c/aria-practices/issue259-aria-level-guidance/aria-practices.html#aria-level

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

- DRAFT -

ARIA Authoring Practices Task Force

31 Mar 2020

Attendees

Contents

Future meeting agendas

menubar updates

Space key and Selenium testing framework

Guidance / range related properties

Guidance / aria-level

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output