You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where there are implications for implementors, developers, or users, in the areas of accessibility, internationalization, privacy, and security, each specification must have a section that describes relevant benefits, limitations, and best practice solutions for that particular area.>
To this end each spec needs to have an accessibility section. For the avoidance of doubt in the reader, the section should be included even if it indicates there are no known accessibility considerations.
It should also have an Internationalization section, to round out the horizontals.
Are there any good templates to follow, or existing specs that speak to accessibility concerns well, especially for similar pure-API standards with no expected UI?
We're blazing a bit of a trail on this. For an API like this where there is definitely no impact on the UI/accessibility, I'd suggest an "Accessibility" heading followed by a very short and simple section that says something like the following:
This specification has no impact on the user interface and therefore there are no accessibility considerations for implementors, developers or users.>
Worth noting that in 2016 the APA WG (that does horizontal review for accessibility) decided that this spec did not need accessibility review, presumably (if my memory serves) because it has no impact on the UI.
Awesome, thanks for the links. The checklist will provide a good format, even if mostly enumerating that this API does not have most of the relevant features.
Note that user agents are likely to have some user interface elements associated with storage APIs even when the storage APIs do not define them - such as developer tools, or for end users to see which sites are storing data. I called that out in a draft PR.
Activity
inexorabletash commentedon Apr 9, 2020
It should also have an Internationalization section, to round out the horizontals.
Are there any good templates to follow, or existing specs that speak to accessibility concerns well, especially for similar pure-API standards with no expected UI?
Add accessibility section draft. Resolves #327
LJWatson commentedon Apr 10, 2020
We're blazing a bit of a trail on this. For an API like this where there is definitely no impact on the UI/accessibility, I'd suggest an "Accessibility" heading followed by a very short and simple section that says something like the following:
akuckartz commentedon Apr 10, 2020
Are there any checklists regarding potential accessibility impacts of APIs?
LJWatson commentedon Apr 10, 2020
There is the Framework for Accessible Specification of Technologies (FAST) with an associated FAST checklist.
Worth noting that in 2016 the APA WG (that does horizontal review for accessibility) decided that this spec did not need accessibility review, presumably (if my memory serves) because it has no impact on the UI.
inexorabletash commentedon Apr 10, 2020
Awesome, thanks for the links. The checklist will provide a good format, even if mostly enumerating that this API does not have most of the relevant features.
Note that user agents are likely to have some user interface elements associated with storage APIs even when the storage APIs do not define them - such as developer tools, or for end users to see which sites are storing data. I called that out in a draft PR.
inexorabletash commentedon Apr 10, 2020
Updated draft, direct link to the new accessibility section is https://pr-preview.s3.amazonaws.com/w3c/IndexedDB/pull/328.html#accessibility
Add accessibility section draft. Resolves #327
Add accessibility section draft. Resolves #327
Add accessibility section draft. Resolves #327
git squash commit for a11y.
inexorabletash commentedon Jun 30, 2020
Anyone want to review the PR?
pwnall commentedon Jun 30, 2020
@inexorabletash Done.
Add accessibility concerns section
LJWatson commentedon Jun 30, 2020
The accessibility section is terrific! Thanks @inexorabletash
Add accessibility concerns section