– DRAFT –
ARIA WG

New Issue Triage

<sarah> jamesn: I hate zoom

<Adam_Page> hahaha

<giacomo-petri> just in time to read it!

<giacomo-petri> :D

<sarah> jamesn: six new issues, the first is potenitally outdated document should be deprecated or have message

<sarah> jamesn: file that against someone else

<sarah> jamesn: because this isn't aria. This is WCAG.

<sarah> aardrian: this is WCAG 1.0

<sarah> melsumner: I'll move it

<sarah> jamesn: spec for menu/menuitem does not provide enough guidance for structure

<sarah> jamesn: sounds like something we could do, agenda this?

<sarah> jamesn: agenda'd for next week

<sarah> aardrian: referring to a sibling-accessible-object vs. sibling element. This feels like an editorial change

<sarah> jamesn: I want to get more clarification from Aaron, so agenda-ing for next week

<sarah> jamesn: do HTML form and dialog elements require an accessible name

<sarah> jamesn: I guess we don't need to talk about this, there's an open PR already

<sarah> jamesn: WPT tests for sectionheader and sectionfooter

<sarah> jamesn: this isn't really ARIA, this is WPT right? Any ARIA implication here james?

<sarah> jcraig: I agree, I think there's a related issue or PR

<sarah> jcraig: will add a link

<sarah> jamesn: Prettier throws errors on PRs opened from forks, this is an editorial issue

<sarah> jcraig: w3c/aria#2295

New PR Triage

<sarah> jamesn: Update computation step 2C for clarity

<sarah> jamesn: anyone else who wants to review? We normally look for three, but if Aaron is good with it. Maybe someone from Apple?

<sarah> jcraig: sure

<sarah> jamesn: remove name required from discussed roles (skipping editorial one)

<sarah> (adding adrian and sarah as reviewers)

<sarah> jamesn: might be good to try to get Matt to review it

<sarah> jamesn: last one, remove important terms from core aam

<sarah> jamesn: this is editorial, already have two reviewers, that's enough

WPT Open PRs

<sarah> jcraig: OK with me to skip this seciton

Deep Dive planning/TPAC Planning

<sarah> jamesn: Sarah's so slow at typing

<sarah> (scribe trolling)

<Adam_Page> 😅

<sarah> Clay: if I can only go for a couple days to TPAC, what are the most impactful days?

<sarah> jamesn: monday and tuesday

<sarah> jamesn: seeing as we have at least one participant from freedom and mozilla, browser interop and use of AT and how we can better work with AT topics would be really relevant and great things to talk about

<sarah> jamesn: this is not the chair's meeting, this is the group meeting, so while we can propose agenda, it's not for us to propose the whole meeting

<jamesn> https://github.com/w3c/aria/discussions/2283

<sarah> jamesn: can also tag with f2f candidate

<sarah> sarah: is there a time by which proposals should be done?

<sarah> jamesn: want to get the agenda done a couple weeks before the meeting

<sarah> jamesn: ideally we start to get stuff done a month before the meeting, but there might be some gaps by that point. The sooner we get topics the better, some people might want to go to multiple meetings, so we have to plan the agenda around when those will be.

<sarah> jamesn: we overlap with AG and a number of other WGs that people will attend as well

<sarah> jamesn: I'm going to keep bugging you every week at these meetings. The deadline is as soon as you think of something, put it in there.

<sarah> jamesn: we could have a whole hour of awkward silence

<sarah> jamesn: (throws Aaron under the bus)

<sarah> aaronlev: (accepts being thrown under the bus)

Discussion tracking for ARIA Notification proposal

<sarah> jamesn: Aadrian has done a great job of reviewing this, but I don't seen any other discussion

<sarah> aardrian: as far as I know, I haven't gotten responses

<sarah> Doug: I don't know if Clay and Keith you want to take this on, or if you want me to respond. I didn't want to step on toes

<sarah> smockle: happy to jump in

<sarah> Doug: Clay and I will work things out, and I'll make sure there are responses

<sarah> Doug: not coming to TPAC, I don't know if Clay and Keith will be, so there will be representation so would be good to have a session on this

<sarah> jamesn: I'm hesitant to do too many deep dives on this. If there's something urgent that needs to be worked out, we can do this.

<sarah> Doug: I hope we don't spend TPAC just bringing people up to speed

<sarah> jamesn: it'd be great to have some real-life demos of this stuff and how it will work

<sarah> smockle: we developed two demos that are used in the native implementation if it exists, and falling back to a polyfill that we made at github. The demo has some issues, so it'd be best to look at not right now

<sarah> jamesn: sounds like we have a potential topic coming up

<sarah> keithamus: would be good to have a topic on it at TPAC so we can discuss

Computation steps, section 2C could be more clear

<sarah> jamesn: have a PR for this, probably don't need to talk about it because we already have reviewers assigned

<sarah> jamesn: Melanie, can we remove the agenda?

<sarah> melsumner: I think we should just ship it if Apple's OK with it

CSS text-transform should not affect computed name

<sarah> jamesn: want to make sure we're all on the same page on this. Melanie, your last comment suggested you're not on the same page

<sarah> jamesn: I think the general understanding as far as I'm aware, is that what is rendered should be what is in the acc tree. So if it's transformed to uppercase with CSS, it should be in the tree

<sarah> melsumner: I thought it was what is rendered to the DOM. Isn't this true for reading order too?

<sarah> aardrian: going to suggest that move into a different discussion

<sarah> melsumner: my perspective is what's reflected in the DOM, not the browser, is the machine-readable part

<sarah> bryan: Right now, browsers in chrome I've noticed transform will actually reflect the uppercase. So if you transform, it will actually reflect that in the a11y tree

<sarah> Adam_Page: I can confirm that, as the original reporter of this I kinda came in guns blazing that it should be the other way. I didn't know there was debate that it should reflect what's in the css

<sarah> Adam_Page: I can confirm that all three browsers do reflect the CSS in the a11y tree

<sarah> Adam_Page: if you copy text to the clipboard, you don't get the transformed text. So that's an intriguing difference but I can accept that behavior and close this

<sarah> scott: we shouldn't be looking for css changes to the DOM, because that's not how it works. The css is reflected in the a11y tree, I don't know if that's a good idea, but it's true now

<sarah> scott: when you copy, it is taking the text from the DOM. Anyone using reader mode or their own user stylesheets they could affect this and hey the name is different? That's weird, but was decided on before

<sarah> jcraig: we in this case, the apple a11y team, has long reflected -- we try to err on the side of exposing what is there. We don't always know why the author has chosen to represent something to the user in uppercase or capitalize or lowercase. But there are a number of specific cases where an AT user needs to know these differences. So I think um

<sarah> for 15 years or so, we've reflected what is rendered in the render tree, not in the DOM. I think that's desirable in those cases. However, there is a text transform fullsize-kana. Going to paste some issues in

<jcraig> text-transform: full-size-kana

<sarah> jcraig: I don't fully understand because I don't read kana, but we're going to make a change for because it results in teh speech engines confused about the context of the characters and misspeaks theme

<sarah> jcraig: will paste that bug in a second

<jcraig> https://bugs.webkit.org/show_bug.cgi?id=261565

<sarah> jcraig: I think there is a CSS issue about this as well. I don't have that one handy. Just FYI, there will be some changes to this. In this particular case it just results in broken behavior. But in general, the capitalization is something we want to reflect to AT users

<sarah> sarah: I just was going to throw out that I can't type and talk at the same time

<jcraig> sarah: capitalization reflected in the ax tree has always been a problem because it results in some mispronunciation

<melsumner> h3's were popularly styled for years as text-transform uppercase, letter-spacing 1px :)

<jcraig> sarah: most times, the DOM reflects the intended capitalization

<jcraig> sarah: so i wonder if the "AT users need to know what's rendered" is actually true

<sarah> melsumner: I've had it drilled into me that this is about machine-readable code. What's in the DOM should be machine-readable, and use CSS to style how you want it to appear. But the underlying markup better be correct

<sarah> melsumner: so I think the issue is actually correct based on how it's supposed to work. I have a strong aversion to saying text-transform uppercase should be uppercase to AT, because I strongly disagree

<sarah> Adam_Page: part of the reason I came in forcefully on this is my own personal preference that aligns with Mel. Also the CSS spec itself says the spirit of this is that it is presentational, so it just seemed to be true to the spirit of that

<sarah> Adam_Page: I can see developers looking at the CSS spec and assuming the a11y tree align with that interpretation

<sarah> aardrian: personally I don't think CSS should mess with this, however as scott alluded, if there is existing behavior and that behavior is consistent, I'm disinclined to blow that up

<sarah> jamesn: I was going to say exactly the same as you just then. If this wasn't the case, and CSS text-transform didn't change the accName, I would say we should leave the behavior as-is. But seeing as al three browsers do the same thing, there must be some reason. Or maybe it was accidental and convenience. THe fact that it's consistent makes me

<sarah> concerned if we want to change it

<Zakim> jcraig, you wanted to say the blind VoiceOver QA team and lots of blind VoiceOver users have solidified the principle to let them know what's actually there.

<scott> agree with james nurthen. i do not like this. i think this should have been a setting. similar to sarah my experience in developing websites and translating designs to code was that designers often used capitalization to visually call out content - not because they wanted ADD TO CART to be announced as A-D-D to cart

<scott> but i also do not think we should change what is implemented in all browsers

<sarah> jcraig: I understand in theory as a web developer the separation of content from presentation, believe it or not the reason I know this history is because this is one of the first bugs I raised to the a11y team when I came in as a web dev in 2006. It wasn't specific to text-transform, it was also about generated content. We had a long discussion

<sarah> with a much smaller a11y team that I later joined. Since then, it's been very very consistent. As far as I'm aware, every blind QA member and also customers on the outside who are blind, now always specific to CSS, in general the principal is always let me know what is always there. This has been a principal that I've kept during my time there.

<sarah> Show me what's actually there

<sarah> jcraig: the fact that it results in some mispronunciations, I think that should be addressed as speech engine bugs

<sarah> jcraig: I don't think it should change that particular scenario. This is kind of a longstanding one I would be against changing it in general

<jcraig> sarah: i disagree for one primary reason... as an author. there is no way to fix this.

<jcraig> sarah: for example: "about us" becomes "ABOUT US" pronounced as "about U.S."

<aardrian> For an example: see the ffconf approach that Remy wrote up: https://remysharp.com/2024/07/23/screen-reading-eff-eff-conf

<sarah> Adam_Page: another example, A-D-D to cart. Another speech engine did pronounce US as "us"

<jcraig> adam: "A.D.D. to cart"

<sarah> aaronlev: kinda like James Craig, I understand the POV of people from the authoring side that think it doesn't make sense. I think the reason all the browsers act like this is getting rid of extra whitespace. If you do "about _ _ us", we fix that by getting the rendered name that gets rid of the extra spaces, which also gets the capitalized text.

<sarah> This is actually not simple to fix, because we'd have to get the DOM text, then do the same logic as the render tree to get rid of the spaces

<sarah> aaronlev: I imagine some pages might be built that assume it's working, maybe we want to put in a hint

<Zakim> melsumner, you wanted to ask jcraig can you explain what you mean by speech engine bug

<sarah> melsumner: I'd like to get some clarification from jcraig about speech engine bug. Also +1 to sarah's blow this up because it's wrong. I can't count how many websites I've made with h3, text-transform uppercase. No matter what we do, it's going to break something because we've implemented something in browsers that doesn't match everythign else

<melsumner> VoiceOver reads "AWS" not as "a-w-s" but "awes" (I've always found it amusing)

<sarah> jcraig: so on every platform, the screen reader isn't usually the thing that does the voicing. For example, on mac systems, both VO and siri make calls out to a speech engine, and each speech engine have one or more voices that can pronounce text. So the speech engine is the thing that is taking the text with one or more attributes. So for mac and

<sarah> iOS, and also for windows and android, not every speech engine knows how to pronounce every language on the planet. Western and eastern languages are handled by different engines

<sarah> acappella and nuance, for example

<sarah> jcraig: I just tried A-D-D to cart with alex, and it does it correctly. I'm going to try it with a different speech engine, and that might be the one that mispronounces it. But it's effectively a downstream software process from the screen reader. FWIW, it's going to get really really good in the next few years with all the advances in language

<sarah> modeling. I think these errors will go away within our lifetime.

<sarah> jcraig: I think that's going to be a solvable problem that will resolve itself over time

<sarah> Matt_King

<sarah> Matt_King: I hear both sides of this, I have a really difficult time thinking about deviating from the show me what's there principal. Because if I have written CSS, I need to know what's there. There's been some situations where people have made stuff caps, where there was a discussion about using CSS to make normative words uppercase. If you do

<sarah> that, you really need to know, but we ended up making it uppercase in the DOM content. But I can still imagine situations where that's what people would do, so I need to know as a blind user what's there on the page

<sarah> Matt_King: I don't know if I fully agree with jcraig that it's a speech engine bug because you need to know so much about the context

<sarah> Matt_King: the bugs I hear from so many screen readers, I don't know that any are better. Unless there's a deterministic way to get authors to say this is not an acronym and this is, and to get speech engines to respect spelling of acronyms. There are so many acronyms and times I capitalize stuff where I want it to be read as individual letters and

<sarah> it's not

<aardrian> Sarah: Going to update my opinion based on what Jamesn and jcraig said. Less inclined to blow things up.

<sarah> sarah: based on what aaronlev and jcraig, where because it's a lot of work to fix something that will be fixed elsewhere, I'm updating my opinion to "likely not worth it"

<sarah> Adam_Page: there is the semantic abbr element for what it's worth, but that would be another proposal to make that more deterministic

<sarah> Matt_King: that's about saying what the words mean, not strictly about saying "A-B-C" instaed of trying to announce "abc"

<sarah> jamesn: and sometimes that's read as a word, and sometimes as letters

<sarah> jamesn: so there is stuff in APA around pronunciation, so some spec is looking at SAML for pronunciation for certain things

<sarah> jamesn: so for certain weird words and abbreviations, but wouldn't want to use that for standard words

<sarah> jamesn: if we decide we need to the text-transform version, do we need a spec change to specify that?

<aardrian> Ref I am not going to share with a comment, Pronunciation TF: https://www.w3.org/WAI/pronunciation/

<sarah> Adam_Page: I think it'd be helpful to state that, because accname just doesn't make any mention of the issue

<jcraig> I could not get 4 different speech engines on my current Mac system to mispronounce "ADD TO CART"

<jcraig> say -v Alex "ADD TO CART"

<jcraig> say -v Samantha "ADD TO CART"

<jcraig> say -v Eddy "ADD TO CART"

<jcraig> say -v Susan "ADD TO CART"

<jcraig> man say

<dmontalvo> Spoken presentation Task Force

<sarah> scott: sounds like something in accname, and an issue in html aam in lieu of the oft-talked-about never-made css aam. And it seems also that maybe someone could be brave enough to make an issue and PR against the css spec to say "lol this is just decorative but also it's not really ha ha ha."

<jcraig> those are terminal commands

<melsumner> @jcraig try Daniel and "AWS Manager"

<sarah> jcraig: each of those voices, alex, samantha, eddy, susan, are run through different speech engines. In all cases it said add to cart, not a-d-d to cart. I understand this is frustrating to say, since we have this one weird bug in one speech engines to address this. What I'm trying to say is we have a number of things in SRs to address this, if we

<sarah> step through char by char we have ways to know casing, e.g. in VO this is done by a higher pitch. This is where users have said they want to know what's there. I couldn't get this particular example but I'm certain there's another one we could get to mispronounce. That we see this between browsers, I think this is an annoyance to devs that this is

<sarah> mispronounced once in a while

<sarah> jamesn: could we get consensus to specify that this is the expected behavior?

<sarah> (various yeses)

<sarah> melsumner: to leave this alone and not change this?

<sarah> melsumner: I'd be happy to clarify that this is how it is, but I don't want to spec that this is desired

<sarah> jcraig: maybe the clarification is that -- (AWS is mispronounced)-- that this isn't correct behavior for the speech engine, but it's correct behavior that SRs should pass along the current caplitalization to the downstream user

<sarah> jcraig: if it gets muddled downstream from that, that's a bug in that particular framework or subset of the stack

<jcraig> melanie is correct that this one is mispronounced:

<jcraig> say -v Daniel "AWS Manager"

<sarah> Matt_King: I agree with that 100%. I'm not so sure that this idea that we shouldn't take anything from CSS is the principal that we want to have. We want AT users to know what is being rendered, they have to be able to be in control of how to understand it

<sarah> jamesn: we take before and after content

<sarah> scott: display none, visibility hidden

<sarah> Matt_King: we take a lot of thigns from css, that was the reason behind css aam

<Adam_Page> +1!

<sarah> scott: I was going to say what Matt said. I agree with the separation of concerns, I get that, and also there are a lot of things that css does contribute to the a11y tree. Whether we like it or not, this is one of them. I understand both sides, but we should make spec changes rather than just argue

<aardrian> +1 to Scott (TO SCOTT)

<sarah> jamesn: I thikn we have general consensus, but not unanimity to this

<sarah> scott: I'll write an issue against html aam for this so it's tracked. I think there's probably a css issue to file to the text that says it's decorative only

<jcraig> corrected pronounced: -v Samantha "AWS Manager"

<sarah> Rahim: I've started tagging css issues with a label, so maybe this could have it too

<jcraig> incorrectly prounced say -v Eddy "AWS Manager"

<jcraig> more issues on the text-transform topic:

<jcraig> w3c/csswg-drafts#3775

<jcraig> w3c/csswg-drafts#3143

<jcraig> w3c/csswg-drafts#3745