ARIA Authoring Practices Task Force Telecon -- 25 Feb 2020

<Matt_King> regret+ Jon Evan Bryan Curt

<scribe> scribe: MarkMccarthy

Release Plan

<carmacleod> https://github.com/w3c/aria-practices/wiki/APG-1.2-Release-1-Plan

Matt_King: we're making good progress on combobox
... carousel, we're waiting on some little fixes but have some time
... gudiance sections, I think we're pretty close. we'll look at aria-level today
... jemma is starting work in the other bugs category, so we're looking to be set up well. james, timing updates?

jamesn: no, no updates

Matt_King: we'll revisit that next week then; wondering when we want to focus more on 1.3

jamesn: joanie was going through a lot of 1.2 issues. things that need to be done for WD and I don't think we have lots of progress yet

range related properties

https://github.com/w3c/aria-practices/pull/1279

Matt_King: jemma added the part on meter, looks close to complete
... wondering - carmacleod would you mind just committing?

carmacleod: i can do that

Matt_King: that'd be helpful!

<carmacleod> https://raw.githack.com/w3c/aria-practices/zcorpan/range-related-properties-2/aria-practices.html#range_related_properties

Matt_King: my other question - jon had suggested that the table in section 8.1 have 6 columns
... 3 columns for required yes/no, 3 for default values for min, max, and now; and then moving this table to the intro section'

<carmacleod> +1

Matt_King: first question: do others agree that making the table more comprehensive AND moving it earlier is good?

MarkMccarthy: +1

Matt_King: right - all the requirements are in one easy to see place, and in a tabular format
... are there any instances in these 6 roles where valuenow has any default?

carmacleod: sort of. spinbutton says it's a supported attr; the default value for valuenow is no current value

Matt_King: so null, essentially

carmacleod: so it's not required, but there's no value

Matt_King: which roles require valuenow?

carmacleod: all the others

<siri> *where are you seeing it?

Matt_King: meter requires it, progressbar, scrollbar, slider ... okay. so this is a good argument for it then
... they're all required, so there's no default, but there's fallback. should we label the column fallback?

carmacleod: one of the reasons we put that in was to tell authors that they were required

<siri> * How to put comments in IRC?

carmacleod: the section it's in is geared toward user agents, not so much authors

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

Matt_King: so, would it be better to have a table that has a default value column, or just leave it out?
... maybe it's better to tell people there's no default

carmacleod: good idea!

MarkMccarthy: +1

Matt_King: carmacleod, would you be able to propose the changes to the table itself and change it the way jon described?

carmacleod: yes i can pose the changes, do a PR right?

Matt_King: it's a branch, so..

carmacleod: oh just push it, sure

Matt_King: yeah, the way we discussed. thanks!
... looks like 8.1 might be skinny if we change it, but then, the others are too. so that's alright
... i wonder if we should potentially combine sections 8.1 and 8.2? or are the headings better?

carmacleod: might make sense to - it'll match the table

Matt_King: oh, well that's also another way to do this. one section with the text and another with the table

carmacleod: let's see how it looks first

MarkMccarthy: +1

Matt_King: reasonable. okay.

ARIA 1.2 combobox triage

Matt_King: only gonna take a quick look
... there's some things I might need some review help

carmacleod: 1336, 1335, 1334, and 1017 seem related; 1017 is the combobox date picker
... so it looks like there's 3
... there -are- 6, but the others aren't strictly related

<carmacleod> https://github.com/w3c/aria-practices/pull/1336

<carmacleod> https://github.com/w3c/aria-practices/pull/1335

Matt_King: darn - need someone to visually look at 1336. that expanded the scope a little

<carmacleod> https://github.com/w3c/aria-practices/pull/1334

Matt_King: this will need code review, test review, and visual design review (there's an HCM CSS change)
... and editorial stuff too
... maybe we'll just wait on this one, i don't think i can finish this one this week
... yeah, we'll revisit this next week w/ more people
... 1335 - we have three approving reviews from sarah, myself and carmacleod; there's only one file changed, the JS?

carmacleod: yes

Matt_King: i'll ping sarah offline to see if she looked at the tests, otherwise i'll ask valerie or simon
... should be doable this week - good
... 1334 - this also should be a light PR

carmacleod: it says draft though

Matt_King: oh! i can take the draft off. i think jon added a commit. im marking it ready for review now
... just need code, test, and functional review. functionality seems good to me though
... carmacleod you were on editorial?

carmacleod: yes, and i approved apparently [laughs]

Matt_King: so that's done
... so really we just need code and test review done by someone that's not jon. i'll ask valerie or simon
... otherwise looks ready

[group deliberating on whether to take up another topic]]

aria-level

Matt_King: people were questioning whether or not to use this with list item
... do these examples in the list item section make sense without context; are they useful?

<carmacleod> https://pr-preview.s3.amazonaws.com/w3c/aria-practices/pull/1109.html#aria-level_listitem_role

Matt_King: i think I want to have aaron leventhal read this, esp. the tree one

carmacleod: that's a good idea

jamesn: yep

Matt_King: i think there was a different approach to doing tree
... like making a treegrid out of a table, and there -isn't- a way for the browser to calculate the values
... i'm not 100% sure how the browser calculates that. we might be able to come up with better examples for row and tree. i'm really murky on the list item one
... we know it's supported etc., but is the better guidance not to inclulde it because it doesn't give value

jamesn: i've never seen a good use of it on list item
... i'd hate to see someone do what's in the example

Matt_King: don't want to suggest anything to the world any of us think is awful

jamesn: i don't even understand the example. you can't just -do- that

carmacleod: in the PR comments, jon said: I think the section 8.2 should also talk more specially when only part of a longer list is rendered due to size of the list, screen real estate or bandwith issues, these examples would also include aria-posinset and aria-setsize. This is an example is a list of potential search categories:

Matt_King: but even if you had a list that was only partially rendered; if I got to it and it said nesting level 5 with -nothing- around it, then what does that even mean?
... specifically, JAWS says something like 'nested list of 5 items' or something like that
... tables tell you the nesting level, not sure with ilsts. but i'm imagining hearing "nested list" and not seeing anything else around it. i'd be really confused

jamesn: so we'd need an aria property that this element is partially rendered, and the cursor needs to sync up with the DOM to fetch the right content. we don't have anything like that

Matt_King: a lot of times when something is visually partially rendered, it's in the DOM --

jamesn: no, not always

Matt_King: presumably, you could get to previous and next, right?

jamesn: not...necessarily

carmacleod: if you're in a virtual buffer, you won't hit that

Matt_King: so then, we're talking about feeds technically

jamesn: yes, but they're not feeds. what we need is a more generic way of doing feeds

Matt_King: when it comes to APG guidance that is correct -today-, is using aria-level valuable on a list item?

jamesn: yes... potentially. if i'm going through lists with other navigable content. if the thing at level one gets scrolled out of the DOM and only level 2 things are there, it's better to keep it level 2 than reset it to level 1

Matt_King: i can agree it's theoretically better, so it's better authors do the best they can - even if there's no way to to make that information consumable in a very useful way

jamesn: i agree it's not perfect. but it's better than those things changing due to content disappearing
... this happens all the time

Matt_King: we don't have an example of this in the APG. is there an example of something in the wild we could mimic?

MarkMccarthy: something like facebook's news feed? or reddit?

Matt_King: well facebook uses the right elements for the news feed etc., or amazon's menu bars, etc.

jamesn: the ones you see a lot are grids, where rows scroll in and out

Matt_King: well that's a widget, and we can kind of handle that

jamesn: yes, if someone is using table commands in their screen reader

Matt_King: with NVDA and VO, as long as there's focusable elements in the table cells, then they'll go through with no problem

jamesn: so that's something screen readers are doing based on inference, or trying to fix behavior

Matt_King: not quite, it's the grid responding to focus; when the last item is focused the grid loads more. NVDA and VO drag focus with the reading cursor

jamesn: either way, there's lists where this happens, but i'm having trouble of thinking examples
... maybe something like google docs where you only get a small amount rendered in the DOM at one time

Matt_King: for this to work in a list, you'd need a massive list where the beginning is truncated

jamesn: we do that, with trees as well

carmacleod: like a filesystem

Matt_King: dropbox. but they load a new page for each folder
... i wonder if box or another one does something like that. uses a list but shows the whole tree

jamesn: our tree view does this

Matt_King: jamesn, do you have any direct suggestions on how to make the list items section of aria-level better or right?

jamesn: yeah. something with aria level 1 and aria level 2 with no UL between them - not sure why we have both levels with nothing between

Matt_King: so, it's clear we need more work here. i don't actually know what to change. suggestions welcome

jamesn: i know the idea is to cover all scenarios, but if -we're- struggling to think of use cases, i wonder if we should even include it?

carmacleod: i thought that too

Matt_King: me too. not having it at all seems a problem, but...

jamesn: we could acknowledge it. something like "it's allowed, please submit one, but we can't think of one or might deprecate in the future" FOR EXAMPLE

carmacleod: [chuckles]

github: https://github.com/w3c/aria-practices/pull/1109

- DRAFT -

ARIA Authoring Practices Task Force Telecon

25 Feb 2020

Attendees

Contents

Release Plan

range related properties

ARIA 1.2 combobox triage

aria-level

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output