Meeting minutes
<Jemma> Meeting agenda: https://
<jesdaigle_> +present
ARIA APG Working Draft Publication Schedule
Matt_King: the plan is to publish APG 1.2 when ARIA 1.2 is a Proposed Recommendation
Matt_King: ARIA 1.2 has unforuntately been delayed, still waiting on some implementations
Matt_King: jamesn took a look recently, and found that we're almost there
Matt_King: ARIA spec might be moving forward soon which means we can move forward, even if it's a little ahead of the PR
Matt_King: does that answer your questions jongund?
jongund: what's there now?
Matt_King: we have the TR. but i've been pointing people to the editor's draft, the only thing that's missing are the changes in the first section and the changelog
jongund: seems strange to me that people come to W3C and this is what they get
Matt_King: the redesign should help with this, so it'll be a website instead of a note
Matt_King: APG 1.2 will be the last version that's TR
Matt_King: as 1.3 or 1.4 stuff gets added in, as long as it's clear it's newer content it'll be good. longer term goal is to makee sure the ARiA AT support tables are in there
Matt_King: as soon as 1.2 is out there, we'll be working on the redesign in parallel, and once THAT'S launched, then we won't have to worry about this again
jongund: the wai-aria-practices-1.2 URL just won't get updated at that point, then?
Matt_King: once the redesign is done, all those URLs will be "deprecated" and redirected
<Zakim> jamesn, you wanted to say that the on color in WHCM should he "Highlight" and the off should be the default color
Matt_King: and we'll make it clear that we let people know that the current stuff is out of date, once it is
<Zakim> Jemma, you wanted to consider stop-gap measure
Jemma: jamesn is doing a lot of heavy lifting on the ARIA stuff to get it up to date. is there anything we can do to be "done" in the meantime?
Matt_King: that's a good question for the ARIA WG or the editors
Matt_King: we're basically making our own plan so we have an evergreen site that we can more effectively edit and serve
Matt_King: especially since our work is different from spec work
Jemma: what if we check in again in a month, if 1.2 isn't published by then?
Matt_King: yeah, can add a monthly agendum, and also bring it up in the editors call
ARIA APG Redesign Project Update
Jemma: good segue to what'll save us from this problem! *wink*
Jemma: any updates for us today Issac?
isaacdurazo: yes!
isaacdurazo: Alex is putting together the new site and template, though it's not ready to share yet it's close.
isaacdurazo: by the end of this week I think we'll have a link to share
isaacdurazo: happy to discuss that next tuesday
<Jemma> https://
isaacdurazo: i'm also planning the first usability study for this, for which i'd also like to plan a feedback gathering/group/meetup with stakeholders (us, here) and external folx, like devs or designers
isaacdurazo: thinking the a11y slack community might be a good place to pull participants from, especially external folx
isaacdurazo: goal is to start collecting feedback from us, here, week of August 16th
isaacdurazo: usability study the following week, August 23rd
isaacdurazo: updates will be published in the redesign repo
isaacdurazo: nothing _big_ to share, but exciting news nonetheless. and something to actually share next week!
Matt_King: i want to make sure everyone understands 1) this is intended to be a starting point to be iterated on - this isn't final.
Matt_King: 2) we made a decision to not make it dynamic. meaning - when we push content to the editors branch, it will NOT update the site. the site will be a snapshot - we're not investing in making it live updated at this time.
<Jemma> I have two questions - 1) timeframe after UX design, 2) content inventory
Jemma: i think Matt_King answered most of my first question. but after the UX design, what's the timeline for everything else?
Jemma: 2) we have lots of good indicies, etc., so how are we going to update that information that's not a core part of the structure? like inventories?
Matt_King: that'll be part of the content migration
Matt_King: i don't think we have the full answers to that yet, lots of discovery to do still
Matt_King: after we're a little further along in the information architecture, we'll have a bit better idea of the size of content needing migration
isaacdurazo: i think a good point is that, after the feedback from us and the studies, is to determine the scope of what's getting migrated and when
Matt_King: which leads to my first question - do we want to make any changes prior to your study?
Matt_King: e.g., we have a few pages for each item (pattern, example, etc.). do we want to break those out further?
<Jemma> mck: thinking about adding third section, "fundamental practice"
Matt_King: i love the idea for the patterns page to use cards. i was wondering if we'd have a fundamental practices page that'd have these too, that could bring various cards together to introduce people to further topics
Matt_King: also wondering if we could have some iconography that'd draw people's attention to each sort of fundamental to help visually categorize things
<Jemma> mck: "sea of practices"
isaacdurazo: i like those ideas. i was working on the patterns page just this week - it's a huge difference to look with the cards instead of a wall of text. i think that it'd be good to have that fundamental card set too
isaacdurazo: let me talk with Alex and see what we can do
Matt_King: if it's a good idea and it delays things, that's fine!
isaacdurazo: once i saw the difference in text vs. "gallery" view, it was huge and i think it'll be so worth it
Matt_King: i wonder if others would agree that this is a good way to go about things, and go along with your ideas jongund
jongund: i'm looking forward to seeing the prototype, it's a little hard to visualize
Jemma: any thoughts from CurtBellew, siri, or Bryan?
siri: one thing _I'd_ like is to be able to quickly check if something is global or not, or what a particular attribute can be used on. is it a state, property?
siri: for instance, can this "aria-current" thing be used on a list? Button? Anywhere? etc.
Matt_King: yes, that's a great idea! we haven't gotten to that section yet, but having a common presentation will be really helpful for APG to provide
Matt_King: for anyone who hasn't commented, and if you'd like to, issue 1 in the redesign repo is a good place to look at the current architecture description and leave your thoughts
<Jemma> https://
Bryan: I haven't had much time to look at it yet, but is there something specific I Could check out?
Matt_King: it's a more general description of the architecture. if you'd rather wait for a functioning prototype, that's fine
CurtBellew: I have nothing specific. What Siri said makes lots of sense to me and I'd like that too
PR Review
Jemma: we'll review as many of these together before the end of the meeting
<Jemma> https://
PR 1895
<Jemma> https://
<Jemma> https://
<Jemma> https://
Matt_King: question for the group/jon on the switch PRs - when we did different forms of the nav menus (menubar, disclosure, tree, etc.), we made the content the same to facilitate comparison. should we do that with the switches too?
Matt_King: maybe an argument against that would be showing a variety of places switches are appropriate, but it seems like it should be a purposeful decision one way or another
jongund: i don't have a strong opinion about it
Jemma: it makes sense to me to have the same _content_ with different coding
siri: having more than oneoption helps them pick something, but if it's confusing, one thing might be easier
Matt_King: maybe shortening the titles to "switch based on HTML [element]" would help
MarkMcCarthy_: as a teacher, having different _content_ helps differentiate the examples, along with a more concise title
Matt_King: oh that does make lots of sense!
Jemma: having different content could help with showcasing different usecases
Matt_King: these are good points! thinking of the nav examples, they look much different in their implementation when side by side.
Jemma: thinking of the redesign again, there's value in exposing different content
Matt_King: i like Mark's points. if others are neutral as far as editorial content goes, i'll go his suggestion
Jemma: focusing on the visual reviews of these switches, then...
Matt_King: are we happy with focus styling with mouse/keyboard?
MarkMcCarthy_: yep
Matt_King: keyboard is working with enter and space, this is a checkbox so we're getting that for free, jongund((?)
jongund: we're scripting the enter key
Matt_King: because the pattern says to?
Matt_King: oh this is a new pattern!
<Jemma> there are event key handler for enter both examples, checkbox and div example
Jemma: so are we deciding that we don't need to program the enter key interaction?
Bryan: You'll actually get some of that by default anyway, so maybe it's better for us to keep it
Matt_King: Windows toggle switches (like airplane mode) don't respond to enter key
MarkMcCarthy_: correct, though they look like slide switches
<Jemma> Group is checking enter key implement in different OS, window and mac
<Jemma> mck: If window does not support enter key then we will only support space key for APG example consistency
Matt_King: If Windows and Mac don't support the Enter key, then we won't either. Which would be weird if it was a button I suppose, but better to keep things consistent.
Matt_King: but we wouldn't want to block Enter on a switch made from a button, though?
Group: No
Matt_King: And it's not so much that we have to mimic the OSs, but we should have some rationale as a TF
Matt_King: either way, no objections to the visual design! that's good. I'd like some input on what MacOS does for switches re: the Enter key
jongund: the best way might be to say that Enter is optional
Matt_King: Oh! That's a really good idea
jongund: and we do that in other places
Matt_King: Very true!
jongund: should we update things to do that then?
Matt_King: I'm leaning that way, because we can remove keyboard handling too
jongund: I can make those changes then, no problem