Skip to content

For future consideration (1.3.1): Should anything that is keyboard accessible also be required have an accessible name/description? #549

Description

@KMSOC

Description
For consideration under 1.3.1 where this applies in baselines: Should anything that is keyboard accessible also be required have an accessible name/description? Should we consider adding this note to appropriate 1.3.1 tests?

For example:

  • a div used as form instruction paragraph
  • a tab stop that doesn't have an accessible name
  • Forms or user controls (caught under appropriate tests already)

Questions to consider:

  • Do blank tab stops create an accessibility issue?
  • Do tab stops on non-interactive content create an accessibility issue?

Which Baseline
To help us address your issue more effectively, please identify which Baseline has the issue:

  • All baselines

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions