Meeting minutes
Check-in on restructure
Matt_King: this is the project to literally restructure all apg content
Matt_King: when we're all done there will be no aria-practices.html file. first step is to move all the patterns and examples to a new content tree
Matt_King: all examples moved, 50% of patterns moved and i'll get the rest moved(now that I finished my dialog novel ;-) )
Matt_King: the redirect is set up too. rich, updates?
rich: one thing we had to do is review PR 2402; i had alex do it because he's familiar with it. he found some differences which are noted in the PR. if you or someone withthe TF could review and make sure it's what we want
rich: that'll allow us to unblock PR 2441
rich: we have 2444, 2450, 2451 ready for your review Matt_King
rich: not blockers, but I don't want to cause a traffic jam either
rich: alex did skip one of the tasks that was noted. most recent task (9) (update coverage report JS) is next
rich: after that, he'll get back to updating the gh-pages project
rich: after these couple tasks, there will be 3 left. we're a little ahead but it'll depend on reviews etc.
rich: i'm sticking to our original plan for now, though, and will revise closer to the end of the week if we'll be ready by TPAC
Matt_King: if there are visual changes about SkipTo, someone sighted will need to check that. my personal most important item is the copyright statement
rich: alex said there are some visual changes due to our config, and his vote is we keep what we have for now
rich: whoever would like to review this, i'll add you. i'd love to have at least one TF reviewer
<jamesn> #2402
<Github> https://
rich: the merging of 2402 would unblock 2441
<Matt_King> Link to pr 2402: https://
jamesn: is there a preview link anywhere?
Matt_King: i can't find one, rich, do we have one?
Matt_King: could Alex get a netlify preview running for us? we'd need that before we could review
rich: i just pinged him, will update if he gets back to me. if we get a preview deployed, i'll have him update the PR.
Matt_King: i'd love to get a volunteer now, then once the preview link is ready they can get in there
Matt_King: we want to compare it to what we currently have
MarkMcCarthy: I can't this week
Matt_King: no worries, Siri can you?
Siri: once it's ready, sure.
Matt_King: i think the recommendation is we reject the visual changes that are present in this PR and keep what we have
jamesn: i'm having a hard time seeing anything that's actually different. it removed jumpto, adds skipto, and some spacing changes. there shouldn't be changes to the library... it's just changing a function, near as I can tell
jamesn: the only other change is when Jon changed overflow-y to `clip`
Matt_King: the version here is the version i don't think PayPal has merged yet
Matt_King: for all practical purposes, this is a fork of the current main, and is Jon's work
Matt_King: this is a CSS issue?
jamesn: it's all inline styling basically
Matt_King: ok - let's get the preview asap so we can review it
Matt_King: i'll work on the other stuff
New issue action planning
Matt_King: time to go through new issues
Accordion documentation... 2443
github: https://
Matt_King: is it common to hide accordion content by changing its height? that seems bizarre to me
Bryan: I wouldn't recommend that, to begin with
Matt_King: we don't typically explain JS techniques (i also thought we were using display: none)
Bryan: display: none and hidden do the same thing
jamesn: if hidden is "semantically" correct, then we should be using it here. if not, lets use display: none
jamesn: [reading HTML's definition of hidden]
<jamesn> https://
jamesn: found this interesting thing - not that it should really be used on accordions
Matt_King: this -could- be an interesting argument for hidden on accordions though
jamesn: does anything support this?
Matt_King: no clue - never heard of it before
Bryan: i don't think it'll work with JAWS, since it doesn't use the browser's ctrl-f
Matt_King: that's JAWS' issue though
Bryan: yeah that's true
jamesn: hidden-until-found is currently only supported in Chromium 102+
<Matt_King> Description of accordion: An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content.
<Matt_King> The headings function as controls that enable users to reveal or hide their associated sections of content. Accordions are commonly used to reduce the
<Matt_King> need to scroll when presenting multiple sections of content on a single page.
Matt_King: we talk about showing or hiding content. so that's clear based on the description, and everything is consistent with the description
Matt_King: we don't talk about, in any pattern, about what elements to use. the APG isn't here to teach or prescribe engineering or functional code, it's only meant as a guide for what to do (not HOW)
Matt_King: and THAT is why we don't discuss the hidden attribute specifically in the pattern
Matt_King: does anyone think we should make an exception for accordion?
MarkMcCarthy: i think it's up to engineers to decide what to use and how to do it
Siri: +1
jamesn: +1
Matt_King: and it's up to APG to guide those considerations?
MarkMcCarthy: right
Why is the Disclosure FAQ widget not an Accordion?
github: https://
Matt_King: i think the answer is you can do an FAQ as an accordion, or a series of disclosure buttons, whatever you want. this is just an example of disclosures.
MarkMcCarthy: I think it goes back to your previous answer - it's just a demo for disclosures, not a prescription for how to make an FAQ/disclosure pattern
Matt_King: makes sense - this is just one type of thing you could use a disclosure for, not THE way to make FAQs. Is there any reason to think we SHOULDN'T use an FAQ?
Bryan: I don't think there's one, I've seen it done both ways, and I don't think one is necessary preferableover the other.
Siri: one includes headings and regions, one doesn't. it's basically interchangeable, and each have their benefits and drawbacks.
Keyboard Interface: List which operable elements (should) respond to SPACE, and which to ENTER #2447
<Github> https://
github: https://
Matt_King: when enter or space does something, it is there?
jamesn: i think he's talking about having it all in one place, rather than each example showing one, both, or none.
jamesn: could be a section in activation behavior, explain the defaults on each platform
Matt_King: space doesn't activate links?
jamesn: no, but it does on buttons. Melanie filed an issue about it, that space should activate an anchor element, since that all can be confusing to a sighted user
Matt_King: would this be better suited to HTML?
jamesn: if you're creating an aria widget, not an HTML one, then where do you put the information for what they keystrokes should respond to?
jamesn: ultimately - this issue is asking for what -current- behaviors are and to have it documented in one place.
jamesn: that's something that a PR could be easily made for
jamesn: i'll add a comment
2 of 4 sliders not compliant with WCAG SC 2.5.2 #2446
<Github> https://
Matt_King: if this is correct, sounds like there's a bug in our sliders
Matt_King: i'd have thought they were all using the same JS, curious
Matt_King: I trust JAWS-test, so there's probably a bug somewhere.
jamesn: but a native HTML range responds to a down event too
Matt_King: are we using one?
jamesn: if even the native stuff doesn't comply here...
Matt_King: then that's a browser bug
Matt_King: regardless - if our sliders aren't compliant, i'd like them to be.
Matt_King: we'd need some mousers to test and look at this
jamesn: reading through 2.5.2, I don't think this applies. it can be undone by resetting the slider's position
jamesn: Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to **undo the function after completion**;
jamesn: is moving the slider a function? not sure
Siri: I thought that'd only apply to buttons that adjust a slider, not one with thumbs
jamesn: right - i don't think this applies here
jamesn: if you were dragging a slider, and you move the cursor off and the slider resets, that'd be really *weird*
Matt_King: and would hinder users with jitters etc.
Matt_King: either way, interesting that there are 2 that work that way and 2 that don't
Matt_King: sounds like the ones that don't comply are just less user friendly?
jamesn: maybe JAWS-test means if you click *on the slider itself* and move away... it changes on.mouse*UP* one 2 of them, and on.mouse*DOWN* on the other two. if that's the case, that's a reasonable change
jamesn: in that case, things should be consistent.
Siri: i didn't even think about using a slider that way, i'm glad you pointed it out
jamesn: still may not be a failure, since you can reset it, even if you don't know the initial state, and that could be an improvement
jamesn: there could be many ways to build in an undo, too
Matt_King: so the problem seems to be NOT with dragging the pointer, it's with a single click on the rail
jamesn: i think so
jamesn: we need the down event though, you can't get fine adjustments without it
curt: i agree - it'd be nonsensical to move it only on the up event
jamesn: the exception in the SC is that the value/slider can be reset
Thanks gang
Next Meeting
<Matt_King> September 5. See you all then