search

w3c / device-posture

Device Posture API
https://www.w3.org/TR/device-posture/
Other
33 stars 21 forks source link

Accessibility checklist #147

Closed darktears closed 3 months ago

darktears commented 4 months ago

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 https://github.com/w3c/device-posture/issues/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.

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.

chris480 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

@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 commented 3 months ago

@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 https://github.com/w3c/a11y-request/issues/84#issuecomment-2150269320 so once your feedback has been addressed, we'd like to close this issue.

chris480 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

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