Meeting minutes
Matt_King: we're going to rearrange the agenda a bit to account for a low beginning quorum
Matt_King: we'll just jump into the new issues
New issue action planning
github: https://
Matt_King: i put some questions in about these issues, didn't want to speak for the group
Matt_King: this issue (2507) is asserting a badge represents a state, so maybe it's not a good thing to put the badge in the accname, rather have an APG pattern or ARIA attr
Matt_King: my question is does a badge truly represent a state? or is it a shorthand for a longer item? e.g. a shopping cart badge/icon
siri: the main issue, for me, is badges are different based on context
siri: for me, it's telling me there's a new item etc.
Matt_King: so you're using "badge" as a term for a different purpose, it sounds like to me
Matt_King: the opener here is specifically talking about the badge that shows up as information adjacent to a link (to a cart, a notification, etc.)
Matt_King: if the content requires action, the badge calls their attention to it
jongund: that's the key. i don't think the badge itself as a concept is important; rather if a UI element has this additional information/state (e.g. whether a colleague is available or not)
Matt_King: the question then is it actually a state?
Matt_King: this matters for us because we talk about roles, states, properties, and states are separate from names
Matt_King: pressed, selected, etc. are encoded into ARIA
jongund: i don't think its a state if it's just providing a description for a UI element
jongund: and a user can't change the state of that
MarkMcCarthy: to me it seems like it might depend on the context. you could change the state of "notifications present" by clearing notifications, emptying cart, etc.
Matt_King: the name provides the title, and this would be a supplement to the title. if it's important enough the intent of the badge is to get your attention
Matt_King: you could say it describes the target, but if it's not actually a description it doesn't help the user achieve the goal
jongund: if that badge is associated with non interactive content, and the relationship is a description, screen readers wouldn't catch that
Matt_King: yeah. ARIA doesn't have any states where the user gets to describe that. we have tokens and booleans, but nothing else. so you'd have "the kind of badge" or "presence of badge"
siri: if there are notifications, or increasing/decreasing cart items, that'd go in aria-live. same with user notifications (e.g. USER is now available, etc.). I don't think badges as a state would help that
jongund: maybe this, in the future, would be handled by aria-details. if -details is for static items, screen readers will have to provide that
<Jem> https://
Matt_King: so then, the opposite approach: is there any reason NOT to include badge content in the accname of a link or button that has a badge? downsides to that?
jongund: if it's relevant information, that's the only way you can guarantee AT users have access to that.
jongund: but what if the badge is on non-interactive content?
Matt_King: lets look at naming guidance and definitions
<Jem> An accessible name serves two primary purposes for users of assistive technologies, such as screen readers:
<Jem> Convey the purpose or intent of the element.
<Jem> Distinguish the element from other elements on the page.
jongund: i think that the opener's solution of adjusting the accname is the only viable solution right now. otherwise we might need a newer algorithm to compute that
jongund: or you're asking AT devs to add new ARIA features to what's the accname. both of those options are cumbersome
jongund: based on my experience in the ARIA WG, messing with accname calculation in browsers isn't a trivial feat. and asking AT devs to do so seems like it'd lead to uneven or a lack of implementation
Matt_King: from the end user's point of view, states and properties are separate from names, so if either changes it can be queried/annouced and it has an event. is there an advantage to separate badge content into that area?
jongund: like you said, we don't have anything that's kind of open ended - we have tokens and booleans. nothing that allows a custom string etc. could also run into i18n issues if we did something like that
Matt_King: propose closing with the guidance that badge content should go into the accname, and that the badge content is consistent with purpose of the accname provided
jongund: i think that works. focus less on the fact that it's a badge; rather focus on describing whatever that additional UI element (badge, icon, whatever) is actually conveying
group: [no objections]
<jongund> +1
MarkMcCarthy: makes sense to me +1
siri: +1
<HelenZhou> +1
<Matt_King> Task force guidance:
<Matt_King> * Including information conveyed by a badge in the accessible name is consistent with the [purpose of an accessible name](https://
<Matt_King> * Accessible name serves the user better than description or details based on the intent of the badge and the intent of accessible name.
jongund: maybe we could add an example of something like this to "providing accessible names and descriptions"
Pattern for browsable 'locked' or 'answered' quiz/test/exam question?
github: https://
Matt_King: might punt this one until we get some more answers
Matt_King: we'll check in on this next week as we get more clarification
jongund: i think this is pretty relevant in online trainings/courses
Matt_King: in my experience, these responses come up in popups, after your answer is submitted. rather than everything being on one page.
Search Landmark example has WCAG Use of Color violation
github: https://
Matt_King: is this an issue with the "search landmark" on this page?
MarkMcCarthy: yes, i suspect it might be an issue with browsers, rather than our pages. the blue text is what's failing, because it's not underlined.
jongund: the issue it seems is that we're not underlining links, i thought that was part of our design
jongund: if the issue is just that links aren't underlined, lets just underline all links. all links in related documents are underlined, so let's make it consistent?
jongund: all links in `main` content should be underlined, i'll work on that
Matt_King: but in other pages, is this the same?
jongund: in other pages it IS underlined - bizarre!
Matt_King: not necessarily - the landmark examples don't use our templates yet.
jongund: no, the other landmark examples are underlined, just search isn't.
Matt_King: Oh! Then yes, if you could look into that
jongund: search, assistive tech, and resources' main content links don't get underlined. every other one is
Matt_King: what about pattern pages - carousel, etc.
jongund: they're underlined
Matt_King: so not a general template problem, something specific to a few pages
jongund: maybe there's some CSS adjustment to work on, i'm on it
jongund: should i make changes agaisnt main?
Matt_King: yeah, i'll figure out how to merge it in
Matt_King: all of the APG pages have landmark examples on them now, so we can rewrite these somehow (in the future) to leverage that
Wrapup
Matt_King: next week we'll hopefully talk about QA planning. we might get some feedback on 2508 and hopefully we can take care of that. let's also plan to talk about 2501