Skip to content
This repository was archived by the owner on Apr 3, 2024. It is now read-only.
This repository was archived by the owner on Apr 3, 2024. It is now read-only.

Screen reader section should mention interaction modes #50

@brennanyoung

Description

@brennanyoung

Something that has proved especially significant for our accessibility work is understanding screen reader modes. In particular, there is a rule of thumb I wish had been more clear when I started: It's easy to put 'forms mode' (aka 'focus mode') content inside 'document mode' (aka 'browse mode') content, but often impossible to get a compliant result if you do it the other way round. This has impact for various 'teams' but it is the front end developers that discover the issue first.

The interaction mode is dictated by the semantic roles of the content. If you get the roles wrong, the screen reader will behave in a very unpredictable way.

In 'document/browse mode' the screen reader usually 'steals' the keyboard input. This can easily come as a big surprise to those designing a GUI for keyboard operation unless they test early with a screen reader.

There is a good introduction to the topic here. Perhaps a link to this article is in order?
https://tink.uk/understanding-screen-reader-interaction-modes/

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions