Hopefully you’re up to speed on why wording of job adverts affects candidate diversity, and have started thinking about how to handle unconscious bias in your organisation (yes, it’s complicated, but it’s also worthwhile). And hopefully you’ve realised, if your website is just pictures of white men in their 30s, that you can do, should be doing, better than this.

But there is still more you can do. And you should want to do more, because you want more customers, great employees, the healthiest growth.

So let’s take a look at your website.

Is the site fully usable by everyone? Honestly? If it isn’t — and it probably isn’t — then that means you’re not getting as many customers as you could.

(If you think we’re talking about a handful of screenreader users here, read this great summary of how diversely inaccessible web design affects the user experience.)

But if people can’t use your site, you are throttling more than just customer growth.

Because your website is your public face, which you use to promote your product or service and recruit new talent, an inaccessible user experience can quickly become a problem of diversity in your organisation. We’ve all been there, right? The potential employer whose website is so painful to use that we just give up. For some people, that’s a frequent reality.

Inaccessible website = less candidate diversity.

Don’t buy into the self-fulfilling prophecy.

“But nobody who uses our website/works in our sector/etc … ” Yeah, and maybe there’s a good reason you don’t meet many people with those requirements. If the only people who can use your website are young people with 20/20 vision and perfect motor control, who work on enormous hi-def monitors, who do you think is going to apply for jobs?

Here are some pitfalls to avoid, so you can be better. Attract more customers and a wider pool of excellent job candidates.

Unreadable text

It’s been fashionable the last few years to use text that is very small and has very little contrast — say, tiny grey text on a white background.

Tempting when: writing hint text; adding additional information; designing mobile views of information-rich pages; you see other players (many of whom should know better) doing it.

Why you shouldn’t: if information is relevant, everyone should be able to find and read it. If information isn’t relevant, take it off your website. From the potential investor using their mobile on a sunny day, to the highly talented potential employee with low vision, to the end user who just wants to be able to know what kind of file they can upload, everybody needs to be able to read everything.

How to fix it: use a contrast checker religiously when planning font colours and sizes. Good rule of thumb: 16px minimum.

InVision basically flunks all the tests. Didn’t you know that only young people with 4K monitors and hawklike vision work in ?

Making people guess what’s clickable (and what’s not)

Also fashionable of late is the departure from obviously clickable links or other graphical elements. Not just links, but icons, tabs … you name it, it’s flat as, and ideally in some pale colour that doesn’t meet contrast requirements. My personal favourite: visual design language that uses recurring colours and elements that are sometimes clickable … and sometimes not.

Tempting when: your page contains lots of links or interactive elements; when you just saw a website or app you liked (but that only requires a third as much content or interaction as the thing you’re designing).

Why you shouldn’t: if you have non-underlined links, people with low or limited colour vision will struggle to perceive where they can click. Same with poor contrast between non-underlined link text and regular text, or between interactive elements and background. People on mobile devices, especially outdoors, may struggle with this too — not least because on mobile there’s no such thing as hover-state, so you can’t even move the cursor over things to experiment.

Even those with good vision will struggle if you don’t use consistent design language to distinguish between things that are clickable and things that are not. Cognitive difficulties, temporary or permanent, just make things harder. So if you want people to find the good stuff on your website, and be impressed by you, they need to be able to use it without getting irritated or giving up.

How to fix it: build a consistent design language, account for lack of colour vision, think about contrast, and remember that all interactive elements need contrast and affordance, not just text. Don’t show ‘disabled’ buttons or other elements that can’t be clicked on — not only do these often have poor contrast, making them hard to read and interpret, but there are also people who don’t understand why clicking on that element doesn’t do anything. Finally, ask yourself if you could reduce the total number of calls to action on any given page (looking at you, LinkedIn), to increase the effectiveness of those that really matter.

You can guess a lot about an organisation by how consistent their approach to design is. LinkedIn has like a million different ways of showing (or not showing) that something is clickable. It makes me wonder what internal communication and structure there is like, and what else is on fire. Plus, do we really need 50+ calls to action per page? (Bonus: LinkedIn has at least made a stab at enabling keyboard navigation. However, for a sighted keyboard user, the pale blue default focus is often hard to spot, and just tabbing through content triggered a YouTube embed to start playing. Boo.)

Meaningless or inconsistent content, but it “looks cool”

Your site is a pristine, never-been-cooked-in kitchen of stylish, ambiguous icons without explanatory text labels. If you’ve at least marked up the icons in code, screenreader users are in the unusual situation of being better informed than sighted users, who have to guess what the icons mean. But if screenreader users are unlucky, you have coded up icons and their text descriptions (or field elements and their descriptions) separately, and named each instance ad hoc as you went along.

Tempting when: you’d rather show icons than words because it “looks tidier”; you don’t want to have to think about how to formulate link text so it’s concise and self-explanatory; you’ve become emotionally attached to the idea of icons (especially your own, home-grown icons); you are building out so fast that you “don’t have time” to go back and review what you called a similar element in an earlier release.

Why you shouldn’t: icons are ambiguous, and this problem only increases when we use something concrete to represent something highly abstract. Because you yourself know what an icon or other visual element means, you may overestimate other people’s likelihood of guessing it correctly. Separate coding up of related elements is at best annoying, but at worse renders the screenreader experience impossible. As for inconsistent naming, that’s a problem for everybody. Confusing or frustrating potential customers or employees is not helping you build your business.

How to fix it: Remember that field sets in forms need marking up in such a way that form field descriptions hang together with the actual form fields. Parcel up icons with their descriptions in the code, while acknowledging that text descriptions help everybody, not just screenreader users. At the very least, test your icons, and follow convention where it exists — but if your user base is very wide, you might consider just dropping icons entirely, as the UK government did (NB: this is the one time I would advocate paying attention to anything the UK Government says or does). And don’t forget to name interactive things consistently, which benefits everyone.

Vipps is a mobile payments system in Norway. If you don’t speak Norwegian, can you guess what the icons mean? I think maybe their main contribution here is to provide larger touch targets 🙃

Keyboard navigation is partial, chaotic, non-existent, or invisible

Default keyboard navigation on the site is a fascinating oddyssey in bizarre tabbing order. Periodically a carousel automatically revolves, hijacking the current keyboard focus as it does so. Focus state doesn’t meet contrast standards against background colour or interactive elements, so keyboard users don’t know where the focus is, and spend a lot of time hitting the Tab key in the hope of triggering some kind of visible animation.

Tempting when: time or budget is short; accessibility is applied as a post-hoc layer on top of existing design/build; you don’t meet real users much.

Why you shouldn’t: because users who rely on screenreaders are people too? But it’s also a common misconception that the partially-sighted are the only ones using keyboard navigation — in fact, lots of people do. Their numbers include those with poor fine motor control who can’t use a mouse or trackpad reliably, and, yes, power users. Enabling good keyboard functionality is important if your -based product or service involves entering much information, and essential if it’s really a lot of data entry. Sure, there are a few things it’s probably not realistic to expect to enable for keyboard use, like if the whole point of your website is to allow freehand drawing. But for nearly everything else, keyboard navigation is peachy, and you should design for it.

How to fix it: Figure out the order that tabbing navigation should go in down the page (treat this like a challenge in responsive design if it helps). Also consider some flavour of “skip to main content” link. Follow and enable standard principles for keyboard navigation. And by all means avoid carousels, which are often used as a means of settling internal disputes about who gets their stuff at the top of the homepage. Don’t do this. Think about how great it is when you get feedback that your site is way more usable or efficient than your competition. Encourage more customers, and more good potential hires, to come to you.

Greg should want to work for you

One of the brightest guys I ever met was a guy called Greg, who was a researcher in artificial intelligence. He had a PhD and a wicked sense of humour. He also had cerebral palsy. He used clomp up the driveway to our house in his specially-made orthopaedic shoes that were a bit like cowboy boots (he was from Oregon). Because the muscular spasticity that you get with CP made it hard for Greg to feed himself, my mum fed him (literally, with a spoon) a couple of nights a week, and I guess other families did other nights. Greg got a car fitted with a special handle on the steering wheel, which he was able to grip, so he could drive. He drove from the UK to Russia with a carload of second-hand clothes to donate to people in need; that was Greg.

Greg, a keyboard user (though I wish now I’d seen what kind!), would probably not be able to use your current website, but he’s exactly the kind of person you’d want to hire. I mean, he’s probably retired now. But today’s Greg, you know? Based on the state of your digital , I doubt today’s Greg would want to work for you.

Question is, what are you going to do about it?

Source link https://uxdesign.cc/if-you-really-want-to-be-a---design-your-web-presence-for-accessibility-793c3a523d3f?source=rss—-138adf9c44c—4


Please enter your comment!
Please enter your name here