- From: Scott O'Hara <scott.ohara@microsoft.com>
- Date: Wed, 2 Feb 2022 20:53:02 +0000
- To: Aaron Leventhal <aleventhal@google.com>, James Craig <jcraig@apple.com>
- CC: James Nurthen <nurthen@adobe.com>, Bryan Garaventa <bryan.garaventa@levelaccess.com>, ARIA <public-aria@w3.org>
- Message-ID: <MN2PR21MB1421276BF220D283F37B3FF9E5279@MN2PR21MB1421.namprd21.prod.outlook.com>
I did that. Chromium reports the link name as “some text” and the desc. As “some text”. Gecko reports the link name as “some text” but drops the description. Webkit reports the link name. Don’t recall seeing the description, but cannot re-verity that right now. AT from my testing generally did not announce the description for this pattern, just the name. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: Aaron Leventhal<mailto:aleventhal@google.com> Sent: Wednesday, February 2, 2022 3:45 PM To: James Craig<mailto:jcraig@apple.com> Cc: Scott O'Hara<mailto:scott.ohara@microsoft.com>; James Nurthen<mailto:nurthen@adobe.com>; Bryan Garaventa<mailto:bryan.garaventa@levelaccess.com>; ARIA<mailto:public-aria@w3.org> Subject: [EXTERNAL] Re: Problem with AccName regarding recursively processed nodes You don't often get email from aleventhal@google.com. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification> I'm not sure without digging in. It's probably easiest to run some comparison tests between browsers. If someone wants to do that, it would be helpful. On Wed, Feb 2, 2022 at 3:26 PM James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote: On Feb 2, 2022, at 12:06 PM, Scott O'Hara <scott.ohara@microsoft.com<mailto:scott.ohara@microsoft.com>> wrote: Yeh… I would have expected this to run similarly to how James interpreted this. Same here. In reality, would clarifying this / correcting this actually cause issues? For instance, testing the pattern I did not run into an instance where the link did not have a name with Webkit, Gecko and Chromium. From: James Nurthen<mailto:nurthen@adobe.com> Sent: Wednesday, February 2, 2022 3:04 PM To: Bryan Garaventa<mailto:bryan.garaventa@levelaccess.com>; ARIA<mailto:public-aria@w3.org> Subject: [EXTERNAL] Re: Problem with AccName regarding recursively processed nodes I have always read the computation of Accessible Name and Accessible Description as separate invocations of the algorithm. I can compute either a description or a name and the same node can be referenced in either calculation. Aaron? How do the actual implementations actually do this? From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>> Sent: Wednesday, February 2, 2022 10:54 AM To: ARIA <public-aria@w3.org<mailto:public-aria@w3.org>> Subject: Problem with AccName regarding recursively processed nodes Hi, Yesterday I received an issue report about the live algorithm code for AccName that I maintain, and I thought it was a simple bug to fix. In looking at this further though, I’m not so sure, and need some feedback from those here to figure out which it is. The problem, the following code results in no accessible name, but only a description. <div id="bob"> <a id="test" href="foo" aria-describedby="bob">Some Text</a> </div> If you remove aria-describedby, then it results in an accessible name as expected. This seems like a simple fix, but it’s not. The reason why this is complicated is because of the following text in the AccName spec. Important: Each node<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fwai-aria-1.2%2F%23dfn-node&data=04%7C01%7Cscott.ohara%40microsoft.com%7Ce972c54675ea43c0ea6608d9e68ce0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794315026688494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EBSnaBi8V4EZ%2FRSzDeZyabitMwCW%2BgAQAc6YiexCZ9s%3D&reserved=0> in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed. This is done to avoid infinite loops. Since the AccName algorithm is linear, the result of it not producing an accessible name is actually correct. The reason being, the algorithm has to be followed in the steps they are documented. If either aria-labelledby or aria-describedby is present, the nodes that they reference have to be followed before the other steps that occur afterwards in the algorithm. As a result, all the nodes that are supposed to be processed if aria-describedby were not present have already been processed because aria-describedby references the same nodes beforehand. And, as the spec clearly states, you can only process a node once and not during any other iterations within the same process. So, this is why this code does not result in an accessible name. My question is, should this be changed, and if so, you should realize that this will impact everything everywhere if it is. Thanks, Bryan Bryan Garaventa Principal Accessibility Architect Level Access, Inc. Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com> 415.624.2709<tel:(415)%20624-2709> (o) www.LevelAccess.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.levelaccess.com%2F&data=04%7C01%7Cscott.ohara%40microsoft.com%7Ce972c54675ea43c0ea6608d9e68ce0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794315026688494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6x81bOr9geDbWedpzQLN%2B%2FVFEIM5fvhMpilx7mmVLWg%3D&reserved=0>
Attachments
- image/png attachment: 51FB8FFB9219453297C0B4BF5767C8EF.png
Received on Wednesday, 2 February 2022 20:53:20 UTC