Meeting minutes
Setup and Review Agenda
Jem: Holiday season is here, let's discuss Dec and Jan meetings
Matt_King: and we have lots to do, everyone has to work through! [laughs]
Matt_King: we'll definitely meet on the 6th and 13th
Matt_King: the 20th is cutting it close to holiday breaks
Matt_King: may need to do some async work
Matt_King: alex, are there any bocoup people working that week?
alex: not sure
Matt_King: hoping to get first support tables from aria-at published, the restructure launched (Which needs redirect work yet)
Matt_King: should we plan NOT to meet the 20th, 27th, and the 3rd?
Matt_King: definitely not on the 27th and 3rd
Matt_King: two big things are landing the restructure and tables..
Jem: sounds like it's mainly bocoup work, right?
Matt_King: we've already done design reviews among us
Matt_King: okay, let's cancel 20th, 27th, and 3rd meetings
MarkMcCarthy: second
<isaacdurazo> https://
Jem: isaacdurazo, can you add a link to the redesign?
isaacdurazo: yes, above
Jem: i'll find time to add my comments
Review design of option for viewing patterns and practices in a list
Matt_King: before we launched the redesign, Shawn Henry gave us feedback, and we got the same feedback afterwards
Matt_King: some folks think the card design is too much scrolling
Matt_King: something like a list view
Matt_King: if we DID include that, it'd be optional
<Jem> https://
Matt_King: someone could choose card view or list view
<isaacdurazo> https://
isaacdurazo: here are mockups of an alternative view
isaacdurazo: i'm also adding a search box
isaacdurazo: should hopefully be a live filter
Matt_King: it's just a search for the patterns?
isaacdurazo: yes
Matt_King: would we want a whole search for the APG?
isaacdurazo: maybe the "Search" on the pattern page is more of a filter, i'm now realizing
isaacdurazo: though i think this filter is useful
isaacdurazo: i also included your feedback in this latest mockup, matt
Matt_King: it might be an issue calling it "grid view" if we're not using aria-grid. maybe "card view"
isaacdurazo: that's a common name too, shouldn't be confusing, i like that
Matt_King: so in patterns and practices, we have iconography for different items - is this design adaptable to one whre there aren't unique icons for every topic?
isaacdurazo: yeah, i think so. if an item doesn't have an icon, the space for the icon can be blank, and we'll align the text
Matt_King: if we didn't have one, maybe a bullet icon or something?
isaacdurazo: yeah, we can think of a placeholder. i don't think we need an icon for EVERYTHING
Matt_King: does this seem like something that should move forward? feedback?
Jem: can you explain a bit what you mean about icons everywhere?
Matt_King: the about page will look more like this in the future, so thinking about that - everything may not or should not need an icon
Jem: makes sense
isaacdurazo: this is the same for practices, too
isaacdurazo: the concepts there are a bit more abstract, so difficult to represent visually
Matt_King: great, this sounds good, engineering can proceed then unless there's concerns
isaacdurazo: i'll make sure i clarify that the current "search" is a filter
Jem: what's the timeline to see implementation of this?
isaacdurazo: howard, alex?
alex: i can probably do it, but depends on when things get merged
Matt_King: support tables are probably a higher priority
alex: so it'd be after that as well
QA results for restructured repository
Matt_King: thank you SO MUCH to everyone who's done reviews on this
Matt_King: there were lots of comments about link text - all of those changes were intentional
Matt_King: there were some other content changes that i'm pretty sure were intentional but i'm going to make sure
Matt_King: there was a lot about spacing and color in different places
Matt_King: lots about it being better in the preview than production, and want to make sure there's consensus
alex: i've been keeping track of feedback, waiting for marching orders.
Jem: i can summarize our feedback and share to the group to make it easier for everyone
Matt_King: let's talk about font size, spacing, and color - where are things problematic?
Matt_King: font size changes, sounds like none of that was desirable. right?
Jem: yes
Matt_King: was that unintentional?
alex: not intentional, but i havne't looked into it
Matt_King: we made changes to warning, advisement, and note class
Jem: my recollection is those changes were good, having headings is good. but small things, like capital letters
helen: i think the style in the preview version looks nicer, a bit more modern. the current warning has a red box all the way around, the new one looks nicer
alex: that was to make the warnings consistent with advisement and notes, just different colors
Matt_King: there's still a wording difference, right? so it's not just color differentiating them, right?
alex: usually warnings started with IMPORTANT, advisement with CAUTION, notes with NOTE
Matt_King: i'm not sure we need both advisement and warning - there's differences between notes and warnings, though
helen: i also like that the preview has more padding between the headings and navigation menu, which i like a lot more
alex: thank you for noticing, I feel validated! [laughs]
Matt_King: an excellent change! maybe we'll want to consider if we need notes AND warnings in the future. but THAT seems like an existing inconsistency, so i'm not super worried now
Matt_King: seems like one thing to fix is the font sizing. spacing, colors, are okay?
Jem: there's broken links we have to fix
alex: just because the branches are different
Jem: what about the footer links?
alex: well THAT's a bug
Jem: jon mentioned that the carousels are broken
alex: i'll work on that too
Matt_King: alex, there's also some merge conflicts, can you look at them or let me know if you need help?
alex: i'm not sure how to pre-emptively solve that, but i think i know what's going on. just cant figure out how to placate github
alex: easily possible i'm also confused
Matt_King: aria-practices.html is getting deleted, so shouldn't be conflicting. weird, maybe something got restored that shouldn't have
New Issue Action Planning
<Jem> Rating slider is not a good pattern #2501(https://
<Github> https://
Matt_King: i'd like Jon and James here for this one, so maybe we'll defer it
Navigation Treeview Example #2477(https://
<Github> https://
Nav Treeview Example
github: https://
Matt_King: so this isn't working properly for Talkback... I know we did some testing on iOS and Android without screenreaders to make sure they at least functioned. but there isn't support for the tree role in iOS or Android as far as I know
Matt_King: this might be a nonissue for us... may be an OS thing if there's no mapping
Matt_King: is this a bug in the code that would NOT require a change to the design of the pattern? or could this be Talkback not distinguishing between activation and expansion?
Jem: i could try it and see how it goes, can add comments here
Matt_King: there's no support for the tree role in Android, so we shouldn't expect it to work. but if it's a matter of something small...
Matt_King: how do you know they're expandable parent items?
MarkMcCarthy: there's a right arrow facing the word, that when expanded turns into a downward arrow showing the child items
Matt_King: we -could- make the arrow icon itself something that talkback can focus on to open the child menu, but then it might have to exist outside of the tree
Matt_King: i don't think theres any way to structure a treeitem such that the icon is separate from the link, AND have them both in the treeitem
Matt_King: if the icons are outside the links but inside the list items, they might work? hmm
Matt_King: i don't think there's a straightforward way to do that
Jem: plus the arrow icons look like indicators more than an actionable item
MarkMcCarthy: the arrows themselves do appear actionable, though are small targets to click on,
Matt_King: and a keyboard user can expand/collapse the list items with the left and right arrow keys
MarkMcCarthy: yes
Matt_King: can you do the same on android? expand the treeitems without changing the page?
MarkMcCarthy: i have to zoom in a bunch, but yes
Matt_King: sounds like we're uncovering some stuff. but it might depend on what iOS and Android do, and/or what JAWS and NVDA do with touch events rather than keyboard or mouse
Matt_King: i would guess screen readers should perceive the arrows as something different, but as is not sure they would
Matt_King: we'll need to think about whether it's possible to structure this so there's an aelement for expand/collapse outside of the treeitem, that's recognizable by touch screen readers
Matt_King: sounds like it has to be outside of the treeitem but inside the tree. not sure how ARIA would handle that, as it relates to child items etc.
Matt_King: this could end up being an ARIA problem - how to make a tree itself accessible to touch-based screen readers
Matt_King: sounds like this is a bigger question then - and a matter of solving some other accessibility issues