There is nothing wrong using ARIA to remediate/fix the
accessibility issues as long as the authors have thorough knowledge on how and
when to use ARIA. At the same time, we need to remember that misuse of ARIA
damages the accessibility much more than not having ARIA. There is a saying
like no ARIA is better than bad ARIA. This blog post attempts to highlight some
of the common mistakes that author does while remediating the accessibility
issues with the help of ARIA.
WAI-ARIA mistake #01: Incorrect
know, most technologies require a certain syntax in order for things to work as
expected. Similarly, WAI-ARIA also requires a certain syntax in order
for things to work the way they’re supposed to. Failing to provide the correct syntax can lead
to unexpected results. Let’s discuss some of the common syntax errors that
author introduce in their code, and result in assistive technologies not
working as expected.
values are assumed to be case insensitive: Role values define the purpose of
objects in the page. Authors often fail to implement these values following the
lowercase convention established by the WAI-ARIA specification. For example,
role=”LINK” can be provided, with the value types in as uppercase letters and
as a result, assistive technologies cannot identify the object as a link.
Authors need to remember that role values are case sensitive, and need to be
typed in lowercase.
spelling for attributes or values: Attributes are often spelled incorrectly.
For example, aria-label might be spelled out as aria-lable. As a result, screen
readers fail to announce the accessible name of the control. Authors need to be
mindful and make sure attributes are spelled correctly.
or invalid role declarations: Authors sometimes declare roles incorrectly. For
example, role=”alert” might be declared as aria-role=”alert”. As a result,
screen readers will fail to announce the live message. Authors need to avoid
such mistakes and make sure to declare the roles appropriately using role=””,
and not aria-role=””.
do not exist or are invalid: Authors sometimes provide a role that does not
exist according to the WAI-ARIA specification, somehow thinking it will still
work, or will serve the same purpose. For example, authors might provide
role=”error” for the error message in an attempt to convey the error semantics,
but there is no such thing as role=”error” in the specification. Authors should
become very familiar with the allowed role values to avoid such issues.
WAI-ARIA mistake #02: Children roles without
Authors frequently define
children roles on objects without first defining their parent role. As you may
or may not know, certain roles cannot be used without their related parent/context
roles. For example, a tab role might be defined without its tablist parent
role. As a result, screen
readers may not work as expected. Some screen reader and browser combinations
will still provide the information as expected, but others won’t, making it a
very unreliable solution. Authors need to make sure that children roles are
provided with their contextual or related parent roles.
WAI-ARIA mistake #03: Parent
roles without children roles
many times we see authors provide a parent role without defining the expected
related children roles. As you may or may not know from the specification,
certain roles cannot be defined without also defining their related children
roles. For example, when menu or menubar roles are defined without the expected
menuitem children roles for related objects, screen readers may not be able to
convey the relationship as expected. Again, some screen reader and browser
combinations will still provide the information as expected, but others won’t,
making it a very unreliable solution. Authors need to make sure that parent
roles are provided with their contextual or related children roles.
WAI-ARIA mistake #04: Invalid
ID value references
frequently see authors providing incorrect or inaccurate ID reference values
for certain attributes. As you may or may not know, attributes are set to only
accept ID references as their respective values, such as the aria-labelledby,
aria-describedby, and aria-errormessage attributes. If authors provide an
incorrect ID value, or assign an ID that does not exist in the document, then
screen readers will not be able to create the reference and announce the
information as expected (ex: the element’s label, the related instructions, the
error message, etc). To avoid these situations, authors need to make sure that
the ID values that are defined for WAI-ARIA attributes are valid.
WAI-ARIA mistake #05: Allowed
WAI-ARIA attributes missing
see authors use WAI-ARIA attributes in ways that go against what is defined in
the specification, hoping to make things better for accessibility. As you may
or may not know, certain roles only allow for certain attributes. As an
example, authors might assign aria-selected=”true” to the anchor/link element,
falsely thinking that screen readers will announce the selected state of the
anchor/link. However, since aria-selected is not allowed on link elements as
per the WAI-ARIA spec, screen readers will NOT announce the selected state of
such an element. On the other hand, when aria-selected attributes are used with
certain roles such as treeitem, tab, gridcell and so on, it can work really
well. Authors need to make sure that the attributes they assign to particular
roles are allowed for those roles.
WAI-ARIA mistake #06: Required
WAI-ARIA attributes missing
sometimes see authors define WAI-ARIA roles without defining their expected
required attributes. As you may or may not know, certain WAI-ARIA roles cannot
be defined without also defining their expected required attributes. For
example, when the slider role is defined on an object, certain attributes such
as aria-valuemin, aria-valuemax and aria-valuenow must also be defined. Failing
to do so results in screen readers not conveying the information as expected.
Therefore, authors need to make sure they provide all expected required roles
and attributes when a particular WAI-ARIA role is used.
Oh, wait! I have a quick
If you are wondering how to catch all these 6 mistakes then use Deque axe tool. Yes, AXE catches all of the 6 mistakes that we have discussed in this blog post. You just need to run the AXE tool and that is all, it throws the issues!