[Object Page]: Accessibility issue: contentinfo landmark should not be contained in another landmark

[bomasap]

Describe the bug

While running Axe DevTools, we encountered the following accessibility issue:

"Contentinfo landmark should not be contained in another landmark."

Root Cause:
In the current HTML structure:

<div id="content">
  <footer>
    ...
  </footer>
</div>

The <div id="content"> is explicitly assigned role="main" and data-landmark-guessed, which signals to accessibility tools that it serves as a main landmark.

As a result, the <footer> element (which defines a contentinfo landmark by default) becomes a descendant of the main landmark, which violates WAI-ARIA landmark roles rules.

Isolated Example

https://stackblitz.com/edit/github-t5j5mn-2urftkct?file=src%2FApp.tsx,package.json

Reproduction steps

1. Access: https://stackblitz.com/edit/github-t5j5mn-2urftkct?file=src%2FApp.tsx,package.json
2. Run Axe DevTools(Ensure to keep the Best Practices toggle on while running the AXE tool.)
3. Observe Accessibility issue.

Expected Behaviour

No response

Screenshots or Videos

UI5 Web Components for React Version

2.7.2

UI5 Web Components Version

2.7.0

Browser

Safari, Chrome, Edge, Firefox

Operating System

No response

Additional Context

No response

Relevant log output

Organization

No response

Declaration

• I’m not disclosing any internal or sensitive information.

[Lukas742]

Hi @bomasap

I wasn't able to reproduce the issue with Axe DevTools v4.10.3. Also, I wasn't able to find an element with the id="content" except for the one you added. Please isolate the issues and follow our contribution guidelines for creating accessibility issues.

[bomasap]

Hi @Lukas742

Thanks for your comment.

You need to turn "Best Practices" Toggle on in Axe DevTools.

[Lukas742]

I did:

Also, please keep in mind that this is only an example. While it should be in general accessible, it doesn't mean complex components that implement other components which may require setting accessible attributes manually, lives up to app standards. So, if an accessibility issue is found in one of our examples, we will gladly fix it, but for this the example needs to be isolated (meaning it should only use the components required to reproduce the issue).
Also, axe showing an error doesn't mean it's an actual accessibility issue that is affecting users as it could be false positive, so please explain why users are affected by this. E.g. by providing the faulty screen reader announcement.

When reporting issues with different testing environments, please ensure that the issue is not false positive, a real accessibility concern is present, and there is an impact on the users.

contribution guidelines for a11y

[bomasap]

Hi Luaks,

Thank you for your reply. I’ve identified the root cause of the issue — the Chrome browser automatically adds role="main" to div#content, which leads to the axe error: “contentinfo landmark should not be contained in another landmark.” I’m currently discussing with the team whether we can remove the #content element altogether.

However, there's still another accessibility issue related to the UI5 Web Components. When the FlexibleColumnLayout component is assigned role="main", and the startColumn contains an ObjectPage component, the same axe error appears: “contentinfo landmark should not be contained in another landmark.” The issue is caused by the <footer> element being nested inside another landmark. Could you please take a look?

If we need to remove role="main" from the FlexibleColumnLayout, could you advise where we should assign the role="main" instead?

I’ve also updated the isolation example — please take a look. https://stackblitz.com/edit/github-t5j5mn-2urftkct?file=src%2FApp.tsx,package.json

https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/contentinfo.html

[Lukas742]

Hi @bomasap

the Chrome browser automatically adds role="main" to div#content, which leads to the axe error: “contentinfo landmark should not be contained in another landmark.”

I'm not aware that this is enabled by Chrome per default, since using heuristics for accessibility, such as inferring landmark roles based on an element’s id, is unreliable. Heuristics depend on assumptions that may vary between tools and browsers, leading to inconsistent behavior. Is this also happening when disabling all plugins you have installed and outside of AXE Dev tools?

The issue is caused by the <footer> element being nested inside another landmark. Could you please take a look?

I drilled down the issue to it's core and you're right, here you can find a minimal reproducible example that shows the issue: https://stackblitz.com/edit/github-t5j5mn-pd4sm2rp?file=src%2FApp.tsx,package.json

I find it strange that Axe DevTools only reports an issue if <div role="main"> is used instead of <main>, because they should give the same result, but as both should report the same error, we will offer a way to configure the role of the footerArea container. Once the linked PR is merged and a new version is published you can use the accessibilityAttributes prop like this for example:

accessibilityAttributes={{ objectPageFooterArea: { role: 'presentation' } }}

[bomasap]

Hi @Lukas742
Regarding the issue of div#content automatically adding role="main", I've identified that the 'Landmark Navigation' Chrome extension's functionality automatically adds role="main". Apologies for the earlier confusion.

Thank you for providing the ability to resolve the <footer> element being nested inside another landmark issue; I will update it once the new version is published."

[ui5-webcomponents-react-bot]

🎉 This issue has been resolved in version v2.9.0 🎉

The release is available on v2.9.0

Your semantic-release bot 📦🚀