PROJECTS
ARIA
Styling focus
Web browsers apply outlines to focusable elements to
indicate focus. It’s fine to leave this default style untouched
but it’s vital that we don’t ‘reset’ this behaviour with outline:none;.Switching focus
<dialog>s are inaccessible by default. When users open a dialog,
ensure that they’re dismissible using esc:$(document).on(“keydown”, function (e) {
if (e.keyCode === 27) {
// do something to close the dialog
}
});And return them to wherever they were before:$(“.open-dialog”).on(“click”, function () {
var whereWeWereBefore = $(this);
// do something to open the dialog
$(“.close-dialog”).on(“click”, function () {
// do something to close the dialog
whereWeWereBefore.focus(); // return the user here
});
});Also ensure that users cannot accidentally tab out of the dialog
while it’s still open by implementing a focus trap (ie redirecting
.focus() when users are about to exit the dialog).CSS order is dangerous
Browsers tab according to the DOM order. However, CSS order:,
which reorders grid items that are aligned with display:grid;,
only reorders visually. This messes up the tab index if said items
contain focusable elements. A better approach is to reorder grid
items dynamically. Consider using jQuery’s .sort() function (or else
the JavaScript equivalent) to rearrange siblings in the DOM instead.// data-order is incremental
elements.sort(function (a, b) {
return +$(a).data(“order”) - +$(b).data(“order”);
});DEVELOPING FOR
KEYBOARD USERS
IN-DEPTHaria-labels and then communicate them during
handoff as comments.OTHER ARIA-LABEL USES
ARIA labels can actually be used on any focusable
element (or any non-focusable element that’s made
to accept focus). When an aria-label is defined, this
label is what is dictated to screen readers instead
of the content within. The resulting effect of this
is really hard to empathise with unless you try
navigating the website using only a screen reader.
Apple users can do this by turning on Apple
VoiceOver found under System Preferences, whereas
Windows users can install either NVDA (https://
nvaccess.org/) or JAWS (https://freedomscientific.com/
products/software/jaws/).
Envision a scenario with a list of articles in a
blog where users have the choice of ordering them
sequentially (ordering articles based on their position
in a series) or by recency (for example when they were
added or last updated). The two filters are aptly named
‘Sequentially’ and ‘Recency’ and it’s fairly clear what
these buttons do, assuming that they’re in close
proximity to the list of articles. Given this context,
the functionality of these buttons is clear.
However, for those with visual impairments (and
that engage using screen readers), this context is
lost and these users are instead left to wonder:
Sequentially? Recency? Wait, what?’
Again, this is another example of when designers
should compensate for the lack of visual context
by writing clear, understandable UX copy and
communicating it during design handoff as
comments, so that developers can then go on to
implement it.
In terms of code, it would look a little something
like this:<button aria-label=”Order chapters
sequentially”>Sequentially</button>
<button aria-label=”Order chapters by
recency”>Recency</button>Visually, nothing changes. However the ‘accessibility
text’ dictates added context for those without the
visual context.STEP 2: ALERT USERS ABOUT ALERTS
When an on-screen element changes dynamically (ie
without page reload), it’s vital to communicate these
changes so that those using screen readers know
what’s happened. Let’s use the sequentially / recency
example from before once again.
In the following code example, aria-live=”assertive”
informs browsers that the content within may