Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: 2869 needs another reviewer
Jacques: I can take it up
jamesn: 2868 is a pdf-aam one so our group may not need to look at it
spectranaut_: Do we want to keep pdf-aam as things we look at on this call?
ZakK: While we don't need it for this PR, I think future PRs may need review from y'all for how we want to map things.
jamesn: Current mapping documents map the reality of how things are currently mapped with user agents. We don't ofter review what the Apple mappings are for HTML elements for example. I don't know if that will be similar here. We aren't experts in this.
ZakK: We may need the groups help if there are things where the mappings aren't clear or there isn't a mapping. Y'all can help us map things.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: 61929 for WPT tests
HaTheo: I did some testing on this and it is inconsistent across browsers. Agree that this PR is needed even though area tags aren't common. Chrome doesn't handle onclick the same as Firefox. Happy to review this and add comments since I was reviewing something similar from Lola.
jamesn: 61892 is administrative so we don't need to worry about it
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: I don't think we have anything for deep dive planning today
spectranaut_: On the 3rd during the deep dive session we'll do a new member orientation since we've had a lot of new members join
jamesn: Since we are getting closer to TPAC I think we should replace this meeting item in future meetings with TPAC planning
Updated on: Add explicit language and direction metadata to AriaNotificationOptions
<aardrian> +1
spectranaut_: Last week we met with the i18n working group and they decided it was okay to not include the metadata in the aria notify options but they requested that we make the reasons why very clear. Daniel outlined this in the PR we discussed earlier in this meeting.
jamesn: So that PR was covering security and i18n things?
Daniel: Yes, it includes both. For now we have an example expanding on the existing spin button example which doesn't have much to do with several languages but jcraig has suggested we should add another example in the ARIA practices guide.
Matt King: We also have a tabs example and one more.
jamesn: I am not sure we want to rely on an example that also relies on Aria notify since that may not ship in this version of the spec.
Matt King: What would be the requirements of the example for this to be good?
Jacques: Are the changes we are making the the ARIA notify spec going to be sufficient to address that concern? Maybe we don't need to update this?
jamesn: That is my understanding of what Daniel said in his PR in the ARIA notify section. The example in there shows multiple languages. I think that is reasonable for now assuming the i18n folks agree. The ARIA practices issue can be filled for the future to add this.
spectranaut_: There is already an issue filled for this.
spectranaut_: I added a comment to the ARIA notify example one to add an i18n example.
With overflow:clip and line-clamp CSS properties, users of AT have a very different content experience than sighted users have
jamesn: We briefly discussed this in triage last week
JohnJansen: I added 3 examples to the github issue. We want confirmation and tests written that the way we want this to behave is that truncation isn't read by assistive technologies, the full item is read even when a truncation is rendered to the screen.
giacomo-petri: There is often a "more" button to see all the text, but for screen reader users that is useless because everything is already readable to them. Maybe there should be a CSS property to also hide the text to assistive technologies?
JohnJansen: Interesting proposal, I can file an issue for it, but that is orthogonal to this particular issue.
JohnJansen: The current behavior of everything being read by ATs is how it works in every browser and has many reasons to work that way. I need an expert to confirm that it is supposed to work that way and we should write a test to enforce that.
HaTheo: Yes, we very much want it to work this way. Some people use screen readers and zoom the text in at the same time. It's annoying to have to click a button to read the rest as a screen reader user. there are some corner cases that have to be thought of but I don't recommend changing this.
jamesn: I don't think we could change because it's been this way for so long. Yes this is a good expected behavior. I also think it would be worth adding a way to hide truncated text as giacomo-petri recommended. You also get into weird situations when there are hover to show more interactions. We should think about how to make all that better.
aardrian: Largely I agree with what jamesn and HaTheo said, but issue mostly talks about screen reader experiences and concerns, but this impacts many other AT users. The issue should also note that some screen reader users are sighted. Should there be a separate conversation about making clipping keyboard accessible the same way scrollable regions are?
Matt_King: I get that it has worked this way for a long time, but to me it feels like it causes a lot of problems for real screen reader users like me. I can't tell what parts are visible and what parts aren't. I can't tell that clipped content is being read to me in the examples given.
JohnJansen: I can fix that in the examples.
Matt_King: The clipped content can be anything, even interactive elements, right?
JohnJansen: Correct.
<HaTheo> yes the clip might even be the name of a button.
Matt_King: This is where I've run into problems, when the volume of content is large and the reasons it is clipped is it's in a collection of some kind. It makes it hard to skip to the content you want to get to that isn't clipped since you have to wade through all the clipped content. I can't tell when it is or isn't clipped so I don't always know when this is causing problems
<HaTheo> +1 to giving authors a way of clipping that might be more friendly and better.
JohnJansen: I can take all this back to the group, and we need to think about having some way to hide the more button with a CSS property, We also may need a way to make it possible to hide clipped content to ATs for some cases.
<aardrian> pretend "keyboard user" includes voice users as well
<jamesn> Switch user too
front-endian-jane: There could be a lot of issues for people who are sighted screen reader users if we give an option to hide things like a "more" button when content is clipped but read because they would lose AT access to the more button, but still see it and may still want to click it.
<giacomo-petri> +1 to Matt_King
Matt_King: We definitely want a way to clip content for AT users too since often content is being clipped to reduce how busy the page is, reduce cognitive overload, etc.
jamesn: There is definitely a problem to be solved that isn't solved today.
Matt_King: We want to think of clipping as not just a visual thing.
giacomo-petri: Having an additional property may be essential for authors to make good show/hide UI's and to properly control their UX in the way they intend. A lot to think about on this.
Unclear purpose of aria-valuemin and aria-valuemax when aria-valuetext is used
Matt_King: For a while I've thought that we've had to make changes to ARIA around this. If aria-valuetext is specified, valuemin and valuemax should not be required. We may want to add aria-valuemintext (or aria-textvaluemin). AT don't really know what to do right now and they can generate some results when things are mixed that make no sense.
jamesn: I think I support most of what Matt_King is saying. Saw this causing weird behavior in an app the other day. My off the cuff proposal would be that value min/max/now are a group. If you specify all three the AT could give a percentage. If you specify valuetext and the min/max/now you want to read the text and the percentage. Just some off the cuff ideas to spark discussion.
<HaTheo> specifying only value text might not give an idea of the range and options, but need to think more.
<Jacques> w3c/
Jacques: Not too much to add but I wanted to bring up this other issue that Sarah brought up (2631). 2290 may be related too.
Matt_King: It feels like we have agreement here so a PR could be brought forward for this. Shouldn't be a huge lift? I might be willing to work on this if it wouldn't be too late for 1.3
jamesn: Yes, post 1.3 we are moving to evergreen so it could go in as a single feature.
Matt_King: I can take up making a PR and driving it forward.