W3C

ARIA -APG

16 Feb 2022

Attendees

Present
Matt_King
Regrets
Chair
Jema
Scribe
MarkMcCarthy

Contents


<Jem> https://github.com/w3c/aria-practices/wiki/February-15%2C-2022-Agenda

<Jem> s/jema/jemma

<scribe> scribe: MarkMcCarthy

APG Issue Triage

<Jem> https://github.com/w3c/aria-practices/issues?q=is%3Aissue+is%3Aopen+created%3A%3E2021-11-01+no%3Alabel+

<Jem> https://github.com/w3c/aria-practices/issues/2220

jem: starting our triage today from November 1st - issue 2220 --

Matt_King: I think we talked about this last week

<Jem> https://github.com/w3c/aria-practices/issues/2114

jem: okay, you try to remember, talking about 2114
... <MarkMcCarthy> jem: since we're doing redesign maybe we'll take care of then?

Matt_King: we're changing no content initially, but we could consider it if it's because of the accessibility of the site

jem: added site design label
... talking about 2111

https://github.com/w3c/aria-practices/issues/2111

Matt_King: I Don't understand what the issue is here

jongunderson: i think it's that when we have an example that's too small for a page, the browser uses scrollbars

jem: this is for example 1.1

jongunderson: i think he's asking that the tabpanel be responsive

jem: +1 responsive design would solve this problem
... i think what might be best is to see if 1.2 solved the issue, or if respnsive design would solve the issue

matt_king: I think i'm just wondering if this is a questdion, request, or what. i don't think we have a goal to make all the examples responsive
... if it's asking us to _make_ the example responsive, we might not want to do that right now.

jem: that said, it shouldn't be that difficult to do that

<jongunderson> I need to go, have a good afternoon

siri: +1

matt_king: but for the examples themselves, making _those_ responsive goes beyond the scope of the example

jamesn: +1

matt_king: in other words, to make all the examples responsive, they need a different presentation. teaching people how to do responsive design isn't the point of our patterns

MarkMcCarthy: +1

matt_king: that's NOT to say we don't want to make it accessible with every interface but...

jem: i think my point is that Isaac will be working on some of that with the new redesign

jamesn: if we can do all of that without changing roles/states/etc., that's a good GOAL, but it shouldn't be a bar to clear for our examples to be ready. that's not what we're trying to demonstrate here.
... even if we pick one or two designs, it might not cover everything that everyone wants to do in the real world

matt_king: that's a good way to put it

jamesn: i'd be happy with putting in a note that "we made no attempt to make this responsive", or noting that these aren't production ready snippets, etc. -- that's not the APG's goal.

<Jem> https://github.com/w3c/aria-practices/issues/2107

jem: moving on, 2107
... <MarkMcCarthy> matt_king: not sure we have to provide an example, but we have a proposed section about states in drafts that covers this

matt_king: maybe this would make a good example though

jamesn: do we have examples for aria-expanded anywhere else?

matt_king: disclosure pattern, menu and tree

jamesn: those are different then... so this might be a nice to have. disclosure is close

matt_king: I'd want to provide an example to alleviate confusion based on "checked" or "expanded/collapsed"
... okay, now thinking about it, an example seems reasonable.

jem: moving on, 2016
... <MarkMcCarthy> matt_king: scott and I are going to work on an example for haspopup, so this might be part of that

jamesn: we should just clarify that this wasn't a substantive change, it's a parity change
... I'll add comments explaining that to the issue

jem: moving on, 2015
... oh this is my issue, we can ignore this. it's just for future reference.
... we can quickly talk about open PRs, then move on to APG site redesign. we've got two issues to push to next week

matt_king: well maybe we can skip open PRs, I have no updates.

jem: Jon finished work for tabs, waiting on Matt to do editorial review

APG Site Redesign

Rich_Noah: right now, we're planning having Isaac come to next week's meeting to show his hi res design of the home page, he's working o the text presentation right now
... as far as getting the repo set up, we need to talk with E&O to make sure things are aligned, but we're on schedule
... we're trying to set a deadline of GAAD in May rather than axe-con

matt_king: but you're planning to be ready for review by March?

Rich_Noah: yep, that's what we're tracking towards

jem: when's the feedback period?

Rich_Noah: as far as the design, i'll have to talk with Isaac

matt_king: ideally, i'd like us to be able to give feedback in real-time, and a few days afterward. keeping in mind this is the starting point
... maybe a week or so tops, because we need to keep moving

Jem: so what about QA, on May 16 that's when we check URLs etc etc.?

Rich_Noah: yep

matt_king: we talked about not having only one design proposal, does isaac have more than one for the homepage?

Rich_Noah: right now he's working on one, but he's trying to keep it directional (rather than different versions with branching decisions)

matt_king: 2/22/22 is gonna be an awesome day!

jem: moving on

Focusability of disabled controls

Jem: <MarkMcCarthy> jamesn: 1st, yes, gridcell options should be visible regardless. 2nd, combobox, why should you have options you can't choose be selectable? 3rd, radio buttons, natively they're focusable, so let's follow native.

matt_king: thinking about the combobox, if it was something like "medium, out of stock" i'd still want to know
... not sure we should necessarily follow native. been working with design team at Meta, thinking that if a disabled element if focusable, it creates a _significant_ issue for a keyboard only user.
... one or two times on a page? sure, not a huge problem, but more than that can be an issue
... potential for a non-sighted user tabbing through many disabled elements, it could add lots of keystrokes for them
... ultimately, i wonder if there's a different way to make it known that they can be called out to be disabled.

siri: would it add confusion for a colorblind or low vision user for something being low CCR (allowed under WCAG for disabled elements) but still focusable?

jamesn: that's a good point

matt_king: maybe the focus indicator for a disabled element should look different to account for that?

jamesn: sounds like a UI problem

matt_king: but if the issue is a perceivability issue...

MarkMcCarthy: it sounds like a complicated problem, maybe we should have more conversation about it

matt_king: i agree

Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
    $Date$