Accessibility checklist

[darktears]

This issue is a record of the Devices and Sensors Working Group's response to the Accessibility Checklist for the Device Posture API. Completed Checklist is required for the submission of the Accessibility review, one of the wide reviews tracked in #146.

Device Posture API: Accessibility Considerations
The specification has an Accessibility Considerations section covering recommendations.

Accessibility Checklist
The Accessibility Checklist document is structured into the following sections, with top-level conditions reproduced here to facilitate WG review. Those with a checkmark are considered relevant to this specification and will be discussed in more detail in the sections that follow.

• If technology allows visual rendering of content

N/A

• If technology provides author control over color

N/A

• If technology provides features to accept user input

N/A

• If technology provides user interaction features

N/A

• If technology defines document semantics

N/A

• If technology provides time-based visual media

N/A

• If technology provides audio

N/A

• If technology allows time limits

N/A

• If technology allows text content

N/A

• If technology creates objects that don't have an inherent text representation

N/A

• If technology provides content fallback mechanisms, whether text or other formats

N/A

• If technology provides visual graphics

N/A

• If technology provides internationalization support

N/A

• If technology defines accessible alternative features

N/A

• If technology provides content directly for end-users

N/A

• If technology defines an API

If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features.

The Device Posture API exposes new media queries and JavaScript APIs to allow developers to lay out content differently according to the posture of the device. Developers will then use existing web platform building blocks to
lay out their content to serve their users better. Developers are expected to follow the existing accessibility
guidelines when creating specific layout for foldable devices.

If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API.

The Device Posture API does not generate any user agents prompt or UI like a permission dialog.

• If technology defines a transmission protocol

N/A

[chris480]

For "If the API can be used for structured content...", thoughts on calling out more explicit parts developers should be aware of that might be specific to posture? I'm not sure if "Developers are expected to follow the existing accessibility
guidelines when creating specific layout for foldable devices" provides enough clarity for WG?

[darktears]

@chris480 I linked the dedicated section in the spec right at the beginning of this post covering some specific foldable accessibility considerations. Don’t you think that’s enough? My comment meant that beside this section developers are encouraged to follow what’s usually expected.

[chris480]

@darktears That makes sense. The only thing I can see within the linked section, is possibly callout an announcement of some sort could be expected by users when a posture state is reached.

[anssiko]

@chris480, could you help us by proposing a concrete addition to the accessibility considerations to address your feedback? Thank you for your contributions.

Accessibility review by APA WG was completed w3c/a11y-request#84 (comment) so once your feedback has been addressed, we'd like to close this issue.

[chris480]

@anssiko certainly can do. Am away from computer, otherwise I would do a pull for review. Here is text I had in mind for the When using this API it is important to consider the opportunities above with accessibility in mind. Here are few concrete examples section:

**Content Announcements for Assistive Devices:** Use ARIA live regions to announce significant layout changes dynamically. For instance, when a fold changes the layout of a webpage, ensure that screen readers announce these changes to users. For example, if a video player is moved to the top of the screen and comments to the bottom, an announcement like "Video player moved to the top screen, comments moved below the fold" can help users navigate better.

**Assistive Technology Compatibility:** Conduct thorough testing with various assistive technologies to ensure compatibility and proper communication of changes when different postures are reached.

[darktears]

@chris480 I gave some thoughts about your comment and I'm not sure if any type of announcement should be expected. Posture changes received by the page are user generated, by that I mean a posture change is triggered when the user physically manipulates the device and changes its posture so the user knows that content will be shuffled around potentially.

The only use case I can think of is someone blind/limited visibility who relies on these announcements to make sure a given posture is triggered. For example, to make sure that the laptop is sufficiently folded to be in the folded posture. However, today's hardware really makes it obvious (even for someone with limited visibility) when the hinge moves from a flat position to a folded position (typically a snap) and the posture is changed right away. Regardless I think this should likely be the job of the OS to announce posture changes, after all the OS also adapts its UX (for e.g. when you undock the keyboard etc etc). I don't think Android has specific support for that and Windows most definitely lacks support for foldables in the first place so... (we had to work with OEMs to fill the gaps).

I can't think about all the use cases since I'm not familiar with the problem space of accessibility beyond the basics so take my comments with a grain of salt. Either way I don't mind adding a text, simply curious what it means for the developers.

[chris480]

@darktears looks like our comments came in at the same time. I do agree that OS should be in charge of handling posture change. However, I am still concerned that the content within a page has not been properly announced of any change.

If I have misunderstood the nature of what we need to communicate in the posture spec, I do apologize, and I'm happy to consider my concerns resolved.

[darktears]

@chris480 indeed we posted at the same time. No need to apologize, these are good discussions.

Out of curiosity, when the resolution of the screen changes (and the content is laid out differently) are developers expected to announce anything? I ask this because it's the same concept, developers will change the layout due to the screen estate change triggered by the posture change

[chris480]

@darktears I do make it a point to use aria-live region updates if the major layout items are moved, hidden, removed. For example a email app where the inbox pane hides itself in a sidebar while the user was focused on it. I don't see many apps do this, but I do believe it is a good suggestion to make.

[darktears]

Make sense I'll add your text then. It doesn't make any harm.