W3C

– DRAFT –
ARIA Authoring Practices Task Force

26 October 2021

Attendees

Present
howard_edwards, Jemma, MarkMcCarthy, Matt_King, sarah_higley, Sarahhigley, siri
Regrets
jamesn
Chair
Jemma
Scribe
MarkMcCarthy

Meeting minutes

<Jemma> scribe anyone?/me

Accordion

tooltip

<Jemma> https://github.com/w3c/aria-practices/issues/128

Jemma: so thinking about what updates we can make, right?

<Jemma> https://w3c.github.io/aria-practices/#tooltip

Matt_King: just want look at what we can try between now/Nov 1 and Nov 8

Matt_King: a super simple illustration/example page, if we can do that between now and then that would be great

Matt_King: at least want to try, it would be very helpful for 1.2. sarah_higley what do you think?

sarah_higley: what i'm working on would be a big changee so i don't think we can review that in time. but if you want something small before the 8th...

Matt_King: well i'm asking if you think there's any small changes _worth_ making more than anything

sarah_higley: a small interim change might bog us down a bit

Matt_King: ok! just wanted input before making an explicit decision

sarah_higley: if anyone _wants_ it i'm happy to work on it

Matt_King: unless there's objection, we'll leave as is for now

Accordions

<Jemma> https://github.com/w3c/aria-practices/projects/8

Matt_King: we merged your first changes sarah_higley, simple stuff

Matt_King: but you have another PR that's basically to add an additional accordion; so we'd have one with static content, one with forms, and this more robust forms/wizard one you made in 1834, right?

Matt_King: is _this_ something we want to land in the next 2 weeks?

sarah_higley: i think i just need to add tests so we should be able to review it

Matt_King: awesome, i'll change it from a draft so we can get reviews done while you're adding tests

<Jemma> https://github.com/w3c/aria-practices/pull/1834

Jemma: since we have howard_edwards with us, i see 1834 is assigned to Jes - do we need to change that?

Jemma: also hello howard_edwards!

howard_edwards: myself and Simon will be looking through Jes' assignments, you can assign them to me

Jes: it didn't disappear, i was just waiting for things to be more ready

Matt_King: Issue 1002 -- I've always thought No should answer those questions, but Bryan had another thought

BryanGaraventa: my concern is I see people using accordions for many things. for simple things landmarking the answers might not be so important, headings might be enough.

BryanGaraventa: but in cases like megamenu structures, those are accordion style interfaces. When someone does that, it's hard to tell where the regions are, especially if the activeelements info isn't there to demarcate boundaries

Matt_King: so if they're not things that should be landmark regions, shouldn't they be labelled groups?

BryanGaraventa: I think the Adobe megamenu structure works in the way I'm describing. groups technically work but doesn't include navigation between regions which might be important

Matt_King: sounds like issue 1002, which is about disclosures and an FAQ example... I'm concerned we'd be conflicting with our landmark advice (like not using too many regions). a long accordion/FAQ then might overpopulate regions

BryanGaraventa: True, you're right. maybe guidance that if something is simple it doesn't need them. I'm thinking of something like settings panels if there's show/hide controls, additional form fields near text, large paragraphs, etc.
… if there are no regions, there's very little that helps you understand where you are. having region nav commands can be really helpful in cases like that

Matt_King: in the accordion pattern you're always supposed to use headings, we discourage regions inside main. if proper heading structure is used, wouldn't it conflict?

<Jemma> "however this guidance does not take into account that there may be many such regions where the only way to ensure proper nesting information is to expose the relevant regions that are applicable."

siri: and they're grouped by list elements.

Matt_King: well accordions aren't typically a list format, we removed the list structure from accordions with help from community feedback

Matt_King: and if we use lists, then you're forcing authors to put other list items inside the parent list item, which may or may not be appropriate.

Jemma: So Bryan mentioned the above quote [that I pasted in a few lines up]. is there a specific use case for this? Or could we use a parent/child relationship?

BryanGaraventa: I don't know anything that works as well as region might. group _may_ ....

Matt_King: headings work really well. normally, in the main content of any document, info in the main region would be under headings...

BryanGaraventa: Well not all accordions I've seen have headings

Matt_King: our pattern, though, recommends using headings for each header

<Jemma> Why don't we use queue for questions?

BryanGaraventa: in a megamenu, there might not always be headings, and they don't always use headings because the styles might change - i've heard reluctance to doing so

Matt_King: would you be opposed to aria-role=heading?

BryanGaraventa: i've recommended it! it helps, but only when they do it

<Jemma> another option is dd dl

sarah_higley: style issues should be solved with CSS. But also, there's lots of places where headings might not be appropriate based on content structure. it seems very "it depends"

Matt_King: i think if we could come up with such an example... i'm struggling with the concept that semantically a region can't substitute for a heading. and if you use a region label, why not use an ARIA heading?

BryanGaraventa: So if you rely on headings to mark boundaries of a dynamic region, if you don't convey the _end_ of that content, it's hard to know when you've strayed outside of it. in the case of something like a settings panel/dialog, that can be expanded/collapsed, it might be easy to leave that area without realizing it. e.g. if there's no headings after it

<Jemma> +1 to Matt

BryanGaraventa: It's a little niche but a relevent example

Matt_King: i'm hesitant to say it should be a landmark region, because landmark regions aren't meant to convey boundaries

BryanGaraventa: We do that for carousels though

Matt_King: did we use role=region for the outer container and role=group for the slide container? i think so

Matt_King: okay so if you put one region around the entire accordion, maybe that'd work. but that'd depend on the context

Matt_King: so back to issue 954...

BryanGaraventa: if there's a simple way to do this without region i'm welcome to it, but I haven't found anything as useful

Matt_King: role=separator with a description?

BryanGaraventa: you can't skip separators with shift-greaterThan in JAWS with separators

sarah_higley: i just want to add that we shouldn't be TOO perscriptive

BryanGaraventa: I agree - i also don't want to encourage people NOT to do something that CAN help accessibility

Matt_King: I also agree

Matt_King: if you can change some wording in 954 to get something useful around the entire accordion widget, maybe that'd be good

BryanGaraventa: That makes sense, that could be useful

Matt_King: does that address things, at least for now, Bryan?

BryanGaraventa: I think so, I can try it out

Matt_King: can you take a look and try it out? See if you can address some wording and all?

jemma: that took care of 1834 and 954

Matt_King: let's take a look at 1814, Jon's PR

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

Matt_King: is there new a11y feature documentation on here?

jongund: yes

Matt_King: any changes to visual design? We could do that now if so

jongund: mostly just some updates to make everything look more consistent with our other examples

Matt_King: does anyone have any concerns about the styling on either of these examples?

jongund: SVGs are also updated to be better in line with HCM best practices

MarkMcCarthy: visual design looks good to me

jongund: should be a big improvement actually

Matt_King: awesome, let's check off visual review

Matt_King: editorial should be pretty quick

siri: i'll check it in HCM

[discussion about different on:hover vs. on:focus styling, generally speaking and not necessarily related to the issue]

Matt_King: moving on, let's look at the visual design for combobox

jongund: overall i think this is a big improvement to the previous visual styling

MarkMcCarthy: i think so too, easy to tell what's selected, where focus is, that the combobox is selected. well done!

jongund: i also added documentation

Matt_King: sounds like the changes are positive, awesome

Matt_King: so then the radio button one...

jongund: this one was fixing styling that i didn't know was broken. it was removed at some point along the line

Matt_King: oh i was talking about 2056, i think I merged the one you just mentioned

jongund: so with scroll-to, commenting out one bit of code seemed to fix the problem

Matt_King: any visual design changes or anything?

jongund: nope

Matt_King: so then that one should be good

Matt_King: thanks everyone, great meeting today!

Matt_King: T-1 week to look at PRs, 1.2 is coming!

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

Diagnostics

Succeeded: s/que/queue/

Succeeded: s/exmaples/examples

Maybe present: BryanGaraventa, Jes, jongund