search

FreedomScientific / standards-support

Contains documentation for Vispero software support of Web standards
https://freedomscientific.github.io/standards-support/
GNU General Public License v3.0
105 stars 11 forks source link

Link role not read using Tab navigation #816

Open jeripeierSBB opened 3 months ago

jeripeierSBB commented 3 months ago

Summary

  1. Go to https://lyne-storybook.app.sbb.ch/iframe.html?args=&id=components-sbb-link-sbb-block-link--block-xs&viewMode=story
  2. Navigate by Tab press

Expected result

It should read that it is a link when using tab navigation.

Actual result

It's only reading the text.

Example

https://lyne-storybook.app.sbb.ch/iframe.html?args=&id=components-sbb-link-sbb-block-link--block-xs&viewMode=story

Additional Information

When using browse mode, it reads "link" as expected.

The links on the page are web components which have their own role "link" on the host. This is correctly recognized by the accessibility tree. As well, in the browse mode it works with JAWS. But whenever using tab navigation, it does not read that it is a link. To compare: NVDA and VoiceOver do read "link" as expected.

Kind of special case: the web component does include a real anchor tag (<a>) in the shadow DOM. However, the role and basic functionality is set on the host to provide possibilities to link elements via aria-labelledby or aria-describedby.

JAWS version and build number

2024.2403.3

Operating System and version

Windows

Browser and version:

Chrome 122 Firefox 123

JAWS-test commented 3 months ago

A link containing a link is sent to the Accessibility API. This is not permitted according to the specification and may cause the problem.

jeripeierSBB commented 3 months ago

@JAWS-test Thanks for your answer. I absolutely agree that this is a unfortunate case, but however:

Weaken it a little bit in JAWS (Like NVDA or VoiceOver) would help around this problems.

JAWS-test commented 3 months ago

@jeripeierSBB I am not from Freedom Scientific and cannot say if the issue is considered a bug and will be fixed in JAWS.

However, I have noticed that the problem does not occur when the link in the Shadow DOM is removed. A very naive question: why does a link need Shadow DOM? And why does a link have to be nested in a link if the specification explicitly forbids it? Don't forget: Links were the first elements when HTML was invented. It pains me to see why something as simple as a link is so messed up. And I say that with all my love for the Swiss railway!

Also, I have found that JAWS displays the links on the Braille display as a link, just not audibly.

kyubisation commented 3 months ago

Hello @JAWS-test

Thank you for your reply, even if it is in inofficial capacity. The reason why we are doing this is because we are creating a design system. We are by far not the first to do this, but usually design systems with web components just nest the anchor tag. We however wanted to provide the possibility to reference the link with aria id refs.

To further explain; The inner link is annotated with role="presentation", in this sense it is not a link in a link, but a role="presentation" in a role="link". I am fully aware that we are bending semantics here, but web components are still a broken standard when it comes to accessibility (e.g. https://w3c.github.io/webcomponents-cg/2023.html#cross-root-aria). It is not possible to re-implement the functionality of an anchor tag in JavaScript to work around the hard limitation of not being able to reference elements inside the shadow root of a web component. Due to this we attempted this solution, of which we are certainly not proud of, but consider the inability to reference the link via aria id refs to be equally bad. We will certainly remove this hack, once cross root aria is possible.

If the stance of JAWS will be in opposition of this construct, we will go the route of other web components and simply inline the anchor tag with no way to add references.

JAWS-test commented 3 months ago

To further explain; The inner link is annotated with role="presentation", in this sense it is not a link in a link, but a role="presentation" in a role="link".

No, role=presentation is ignored by the browsers, which is why it is really a link within a link in the API

sbb

JAWS-test commented 3 months ago

As I said, one solution would be to keep only one of the two links and actually remove the link role from the other element, e.g. by using a span element instead of an a element

jeripeierSBB commented 3 months ago

As I said, one solution would be to keep only one of the two links and actually remove the link role from the other element, e.g. by using a span element instead of an a element

This is sadly not possible because we need the functionality of the real link. This is either in terms of SEO but also browser stuff like bookmark it or open in ned tab/window and so on. As written above it‘s not possible to extend an HtmlAnchorElement in all browsers.

In fact, our implementation isn’t nice at all, but we couldn‘t find any really good solution so far.

stevefaulkner commented 4 days ago

@jeripeierSBB The examples you provided are no longer available. But i agree with @JAWS-test If you don't use HTML according to the rules, then odd things will happen.