Umbraco is "The Friendly CMS" and, as a community, we aim to be warm and welcoming, greeting everyone we encounter with a Friendly high-five. But how can we inject some of this Friendliness into our work and make the websites we craft as Friendly as possible?
friendly
behaving in a pleasant, kind way towards someone
To be Friendly to everyone, we need to make sure everyone can use our websites. This simple concept is the whole premise behind, what may initially sound daunting, accessibility. Contrary to popular belief, accessibility isn't all about screen-readers, it's about the usability of your website to anyone, no matter their personal needs.
accessibility
the quality or characteristic of something that makes it possible to approach, enter, or use it
Accessibility of the Umbraco back-office has started to take shape over recent months: in any new Umbraco release, there’s been a whole section of the release notes dedicated to accessibility improvements. This has brought the concept of accessibility to more and more community members, but to some, an accessible website still seems like a distant pipedream - at best a low priority ticket on a backlog and at worst dismissed in the planning stages.
But I’m here to challenge that and show you how building a more accessible site is easier than you might think, whether you're a developer, designer or working in management, sales and delivery.
Accessibility as a priority
Of course, time and budget dedicated to making your website as accessible as possible is the best option and there are many reasons to do so, morally and financially.
We think of the web as open-access and a level playing field giving everyone access to the same information. And it is. For the most part. Building accessible websites is a very simple way to open up information and services to more people, ensuring people are not unfairly restricted by their circumstances.
It’s also important to remember that these are customers. Just as a shopkeeper wouldn’t put a barrier across their entrance only serving those who could jump it, why should a website put up these virtual hurdles for a percentage of potential customers?
I’m sure you’re all aware of the Domino's Pizza lawsuit that hit the US Supreme Court last year, but other big names like Nike, PornHub and Beyonce also got taken to court in America with other countries catching on. Web accessibility will soon be a must-have for all big corporations and any website built today should be taking this seriously.
It’s just UX
User experience (that’s UX to those in the know) designers pride themselves in designing great experiences for users (I guess the clue is in the name!) rather than something that simply looks good.
No surprises here, that this way of thinking generally includes those with access issues. As the word “accessibility” implies, this kind of UX doesn’t exclusively help those with specific needs - it’ll help everyone.
Any user of a shiny phone screen on a bright sunny day will appreciate high contrast ratios between text and the background, while any person who’s had an exhausting day will appreciate concise language and clear actions. Not to mention the 1 in 8 men who are colourblind (myself included) and the huge proportion of us who will develop motor, sight or hearing-related issues in later life.
Accessibility is vital for some and useful for everyone. Accessibility is a part of UX, so let’s be sure to embrace it and hold it in as high regard as visual appearance.
As a designer, thinking about how a user might interact with your design is a part of the job and accessibility fits right in with the other best practices you’re already following. There’s nothing extra here except a few additional things to think about and the more accessible designs you produce, the easier it becomes.
Coding is key
As developers, the way we code our sites makes all the difference. Even if there's no special budget set aside or we've received a design that hasn't fully considered accessibility (or there's no design at all!), we can still make all the difference.
It's not that different from coding without considering accessibility: just as we support browsers by writing valid markup, we can support as many people as possible by writing valid, semantic markup. The key to accessibility for developers is that actually, most HTML we write is probably accessible already. HTML renders in an easy to read and understand way and if we’re using the right semantic markup, it goes a long way to being understood by screen-readers too. It’s good practice to use the right elements for the right things: a nav for all navigation areas; main for the primary content of your site; header, footer and section elements for splitting up the page; and by using headings correctly*.
The trouble comes with JavaScript and CSS.
When styling, a good indication of breaking some bad practice is if you set a style to none or inherit. Browsers almost always have a reason for styling something a certain way, and if you’re undoing that it could make it harder to use.
Accessible accessibility tips
For you designers, developers and testers reading this, here are some of my top tips for starting on your accessibility journey. There is a lot more to learn out there (Jeffrey and Jorgen's article from 2015 is a good place to look for expanding your knowledge next) but this is a good place to get started.
I have 3 golden rules for styling accessibly.
1. Let me outline this for you
An outline is the browsers’ default way of showing focus - by removing this, it might make navigating your site by keyboard impossible! Consider changing the outline colour rather than removing it completely, or use some other clear styling to highlight focus.
2. Which links nicely onto...
By removing the colour and underline from a link, you make it less clear that the text is actually a link! Even changing a link from blue to any other colour can make navigation confusing to some users.
If you’re trying to make your link look like a button, you might confuse people even more.
3. Things that look like things they are not
Using elements for things they are not is another red flag. Using a link as a button or button as a link means the user doesn’t get the functionality they expect from that kind of element - links navigate you to somewhere else, while a button interacts with the current page. A checkbox is a form field, not a toggle for a menu.
It’s not necessarily wrong to use an element for something different, but it is a warning sign. So if you are, you should be sure to try using the component with a screen-reader (I recommend using NVDA over Windows Narrator - it's free and very popular) and only using keyboard navigation. If something is unclear or doesn't function as expected, use ARIA attributes and JavaScript to correct any confusing behaviour.
Don't label me a cynic
Moving on from styling, another really quick tip to make your site accessible is to label things. If an input has no label, or a section has no heading, consider adding one that's “visually hidden” or through aria-label. Similarly, if you have an icon with no text, it’s generally worth adding some text to help people understand its meaning (it might not be as obvious as you think), but if your design prohibits this, aria-label it!
Conversely, an icon that has no semantic meaning, can be aria-hidden so that it’s not read out by a screen-reader. An example of this would be an icon with a label next to it - the icon adds no additional meaning to the label, so a screen-reader doesn’t need to read it out.
Alternative thinking
Alternative text (alt attribute) on images have a couple of really handy uses. Firstly, if your image can't be loaded for whatever reason, it is replaced by the alt text to give an idea of the context it was meant to provide. Secondly, alt text can provide an audible description of the image for blind users and more clarity to a partially sighted user.
*A note on headings
Although it’s valid HTML to use an h1 per section, some screen-readers (as well as search engines) struggle to understand the structure of the content like this so it’s still considered best practice to use one h1 element per page.
In inconclusive conclusion
These are just a few pointers to start you on your accessibility journey. I'm by no means an expert and this is by no means all there is to know but I am keen to make my sites as accessible as possible and learning more every day, which I hope I have managed to rub off on you too! Don't hesitate to reach out to me if you have any accessibility queries or get involved with the Accessibility Team, we're all quite Friendly.
Top comments (0)