Criticality
Medium
Description
We made lots of accessibility mistakes on the past years. Is important that we have some documentation regarding how to not make these same mistakes once again.
"Those who cannot remember the past are condemned to repeat it"
George Santayana
This idea comes from several mails from @ahukkanen who fixed lots of accessibility issues:
Going further, I'd still like to see some kind of accessibility guidelines for UI developers so that we could avoid some of the issues from there. There are still outstanding issues and other issues that could re-appear if these are not guided for UI developers.
If these issues were taken into account, the accessibility fixes would've been much easier and would not have required changes in almost 600 core files. Going forward we should not repeat these mistakes over and over and we should make sure all UI developers are following these guidelines.
Related issues or links
Here are some of his notes, all the credits for Antti ❤️
Next tasks:
Screen reader users
Always when defining elements, make sure they make sense for screen reader users. When you write "read more", the screen reader user might ask you "read more about what?". When you have a visual control which allows you e.g. to add a project to your vote and it is indicated with an icon without a label, the screen reader user will hear the SVG <title> element "check".
When creating new elements, always think that some people may not be able to see them with their eyes.
In particular, take these accessibility criteria into account:
https://www.w3.org/TR/WCAG21/#link-purpose-in-context
https://www.w3.org/TR/WCAG21/#focus-order
https://www.w3.org/TR/WCAG21/#headings-and-labels
Dynamic form filtering
Changes in the form inputs should not change the context of the page automatically. I.e. by default dynamic filtering is forbidden by the accessibility criteria.
However, if you explain such functionality in advance (i.e. advice the user), it is allowed.
HTML validation
You need to follow the HTML standards and ensure they are writing valid HTML. Having invalid HTML is most likely to cause accessibility issues with some devices/accessibility software.
On the past, we noticed few mistakes that were repeating that could've been easily avoided in case the UI developer put few minutes to think about the element structure:
- Generally, do not use
<main> in subviews, there can only be one <main> element per page (so if you add one, make 100% sure there isn't one already on that page) / https://html.spec.whatwg.org/#the-main-element -- "A document must not have more than one main element that does not have the hidden attribute specified."
- When using a
<section> tag, ensure it has an identifying heading element (h2-h6) / https://www.w3.org/wiki/HTML/Usage/Headings/Missing -- "Each section should be identified, typically by including a heading (h1-h6 element)as a child of the section element."
- When using an
<article> tag, ensure you are semantically defining an <article> level content. E.g. a proposal card or a blog article teaser are not semantically articles that define "A complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication." (https://html.spec.whatwg.org/#usage-summary-2). If using an <article> tag, ensure you are describing the full content of the article and also defining the heading element inside the article (see same issue for <section> element).
- When defining an ID attribute for the elements, ensure the values of those attributes are unique on the page. E.g. when a filtering form is doubled for desktop and mobile, the doubled filtering control inside that form needs to have a unique ID in both of its parent elements.
WCAG 2.1 / A-4.1.1
Criticality
Medium
Description
We made lots of accessibility mistakes on the past years. Is important that we have some documentation regarding how to not make these same mistakes once again.
"Those who cannot remember the past are condemned to repeat it"
George Santayana
This idea comes from several mails from @ahukkanen who fixed lots of accessibility issues:
Related issues or links
Here are some of his notes, all the credits for Antti ❤️
Next tasks:
docs/development/accessibility.mdScreen reader users
Always when defining elements, make sure they make sense for screen reader users. When you write "read more", the screen reader user might ask you "read more about what?". When you have a visual control which allows you e.g. to add a project to your vote and it is indicated with an icon without a label, the screen reader user will hear the SVG <title> element "check".
When creating new elements, always think that some people may not be able to see them with their eyes.
In particular, take these accessibility criteria into account:
https://www.w3.org/TR/WCAG21/#link-purpose-in-context
https://www.w3.org/TR/WCAG21/#focus-order
https://www.w3.org/TR/WCAG21/#headings-and-labels
Dynamic form filtering
Changes in the form inputs should not change the context of the page automatically. I.e. by default dynamic filtering is forbidden by the accessibility criteria.
However, if you explain such functionality in advance (i.e. advice the user), it is allowed.
HTML validation
You need to follow the HTML standards and ensure they are writing valid HTML. Having invalid HTML is most likely to cause accessibility issues with some devices/accessibility software.
On the past, we noticed few mistakes that were repeating that could've been easily avoided in case the UI developer put few minutes to think about the element structure:
<main>in subviews, there can only be one<main>element per page (so if you add one, make 100% sure there isn't one already on that page) / https://html.spec.whatwg.org/#the-main-element -- "A document must not have more than one main element that does not have the hidden attribute specified."<section>tag, ensure it has an identifying heading element (h2-h6) / https://www.w3.org/wiki/HTML/Usage/Headings/Missing -- "Each section should be identified, typically by including a heading (h1-h6 element)as a child of the section element."<article>tag, ensure you are semantically defining an<article>level content. E.g. a proposal card or a blog article teaser are not semantically articles that define "A complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication." (https://html.spec.whatwg.org/#usage-summary-2). If using an<article>tag, ensure you are describing the full content of the article and also defining the heading element inside the article (see same issue for<section>element).WCAG 2.1 / A-4.1.1