:focus-visiblepseudo-selector is now supported in Firefox, as of version 85 which shipped yesterday.
The strategy has largely been an all-or-nothing choice between using a custom
outlinewhen any element is in
:focus(great, but that means for both keyboard tabbing and mouse clicks) or ditching the
outlinealtogether (not great, like ever).
:focus-visibleaccomplishes the same thing as
:focus, but uses a browser's knowledge of user inputs (or heuristics) to determine whether the focus is coming from a keyboard or a mouse. (Are a browser’s heuristics perfect at determining the input? That depends. Things get murky once we start factoring in things like touch interactions.)
aria-descriptionattribute is similar to
aria-labelin that both provide a flat string to associate with the element, but a label should be concise, whereas a description is intended to provide more verbose information."
source: ARIA 1.2
The good vibes about
aria-descriptionis that once implemented in the browser it will automatically have the same level of support as
aria-describedbyas they are both the source of text for the accessible description property in accessibility APIs. In fact it's already implemented in Firefox/Chrome/Edge on Windows (and other platforms too with Firefox) and is announced by screen readers [...]
The bad vibes the accessible description content is, currently, only announced on a subset of roles/elements; such as interactive elements.
Ask yourself could the content I am going to hide away from many people actually be useful to them?
After this exploration we had a good idea of what a good focus state needed. It needs to have a high contrast but not impair readability of the underlying components. It has to guide the user to the next focus target with a form of transition. And it only needs to show for users benefitting from the focus outline. Let's also not forget that the package needs to be very developer friendly and easy to implement.
- It respects
prefers-reduced-motionand there's an open issue to discuss what other accessibility preferences it should handle natively.
The need for manual accessibility testing will never fully go away. There is simply too much nuance for computers to make websites and apps intuitive and accessible without human review.
If your pages contain many links or elements before the main content, consider adding a link to the very beginning of the page to help keyboard-navigating users jump directly to the content they care about.
Many web developers who implement skip links opt to hide the skip link, so it doesn't clutter the page for those who don't need it. This is fine, so long as you make the link visible on focus. When a user tabs to the skip link, it should display prominently, so sighted keyboard users don't miss it.
[...] give your target
tabindex="-1". When a user follows our skip link, we want their keyboard focus to move to our target. Modern browsers will move that focus for us, but some older browsers will only move the focus if the target is focusable. If it's not focusable, the page will scroll down but the user's focus will still be at the top of the page.
You can't fail something just because you, the individual, don't like it.
You have to kill your ego as an accessibility auditor. You can’t treat each project as a moral crusade, as much as it might feel like you need to.
An audit can feel like an opportunity to express yourself and your beliefs as an individual. However, it is important to keep in mind that audits ultimately need to be both accurate and actionable. By scoping your work to the actual, objectively demonstrable problems in an inaccessible digital experience you are able to help facilitate a trusted remediation process. This helps the organization you are auditing, your peers, and most importantly, the disabled person who needs access.
It’s always worth having at least one screen reader set up on your computer to test your website during development. The more comfortable you get using a screen reader, the easier it will be to spot issues in the code. When testing your websites with a screen reader, make sure you lower the brightness on your screen or turn your monitor off completely. This can stop you missing mistakes and errors.
As someone that uses screen readers on different devices every day, it’s often the same issues I come across time and time again. Some of the most common accessibility issues I regularly encounter include:
- unlabelled links and buttons
- inaccessible web forms
- no heading structure (H1s, H2s, H3s)
Using the correct HTML elements for their intended purpose means screen reader users can better navigate your web page. [...] Headings and subheadings make it much easier for screen reader users to navigate the website. When these elements are coded correctly, they help signpost the screen reader user to the information they need.
Ultimately, building accessible websites shows that you care about disabled people. Who, as a group, often feel forgotten and left behind. But when a website goes that extra mile to consider accessibility, we feel included and valued.