Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

role=application shouldn't be treated as landmark #4663

Open
1 task done
VitalyM opened this issue Jan 3, 2025 · 2 comments
Open
1 task done

role=application shouldn't be treated as landmark #4663

VitalyM opened this issue Jan 3, 2025 · 2 comments
Labels
best practice fix Bug fixes rules Issue or false result from an axe-core rule
Milestone

Comments

@VitalyM
Copy link

VitalyM commented Jan 3, 2025

Product

axe-core

Product Version

No response

Latest Version

  • I have tested the issue with the latest version of the product

Issue Description

Expectation

Element with role=complementary should be valid inside element with role=application

Actual

AXE treats it as error. RuleId = landmark-complementary-is-top-level

How to Reproduce

<body role="application">
  <div role="complementary">some aside thing</div>
</body>

Additional context

w3c spec doesn't have application role among landmarks
but AXE treats it so:

application: {
        type: 'landmark',
        allowedAttrs: [ 'aria-activedescendant', 'aria-expanded' ],
        superclassRole: [ 'structure' ],
        accessibleNameRequired: true
      },
@VitalyM VitalyM added the ungroomed Ticket needs a maintainer to prioritize and label label Jan 3, 2025
@dylanb
Copy link
Contributor

dylanb commented Jan 3, 2025

I don't believe that complementary is valid inside application because you should not be able to navigate directly to the content inside an application item, the application is supposed to manage the "focus" directly using aria-activedescendant

@WilcoFiers
Copy link
Contributor

I agree with @VitalyM. This shouldn't fail under landmark-complementary-is-top-level. This is allowed by ARIA. There are accessible ways to do this.

Dylan does have a point that this may create other problems, but without seeing the entire example that's hard to say. As long as focus is properly managed inside role=application there is no problem here. We have an issue open to find some way to report problems with role=application (#1191), but this has proven difficult. Axe-core may not be the right tool for testing role=application.

@WilcoFiers WilcoFiers added fix Bug fixes rules Issue or false result from an axe-core rule best practice and removed ungroomed Ticket needs a maintainer to prioritize and label labels Jan 9, 2025
@WilcoFiers WilcoFiers added this to the Axe-core 4.11 milestone Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
best practice fix Bug fixes rules Issue or false result from an axe-core rule
Projects
None yet
Development

No branches or pull requests

3 participants