{ "version": "https://jsonfeed.org/version/1", "user_comment": "This feed allows you to read the posts from this site in any feed reader that supports the JSON Feed format. To add this feed to your reader, copy the following URL -- https://axesslab.com/feed/json/ -- and add it your reader.", "home_page_url": "https://axesslab.com", "feed_url": "https://axesslab.com/feed/json/", "title": "Axess Lab", "description": "Digital accessibility consultants and products", "items": [ { "id": "https://axesslab.com/hand-tremors/", "url": "https://axesslab.com/hand-tremors/", "title": "Hand tremors and the giant-button-problem", "content_html": "

In this article we\u2019ll examine an overlooked accessibility problem that mainly affects users with hand tremors. It\u2019s in almost every interface out there, but barely ever highlighted in accessibility guidelines or discussions. It\u2019s also super easy to fix!

\n

\"Phone

\n

We\u2019re writing this together with Erik Zetterstr\u00f6m of ICT Enablers.\u00a0Erik has worked with accessibility products, services and standardization since graduating in 2003, with a Master of Engineering in Computer Science. A few years ago Erik was diagnosed with Parkinson\u2019s disease.

\n

Have you ever clicked something by accident? Most of us have. Maybe as you tried to scroll on your smartphone while on a bumpy bus, train or car ride? Annoying, right!

\n

For a lot of people with hand tremors \u2013 caused by for instance Parkinson\u2019s disease or essential tremor \u2013 unintentional clicks happen all the time. Especially while scrolling on a touch screen.

\n

If you think about it, touch screen scrolling requires a lot of fine motor control. You need to place your finger on the correct part of the screen, flick it at the right speed and in the right direction, and most importantly: keep it on the screen at all times during this gesture.

\n

Oops! I clicked it again

\n

Many web and app interfaces are designed in a way that causes big problems for users who have a hard time with this scroll gesture. Luckily, there are simple ways of making your interface more hand-tremor-accessible. Let\u2019s dive in!

\n

A lot of sites and apps contain lists of clickable things, for instance products or news articles. These are usually placed back-to-back, with no space between the touch targets. Like this:

\n

\"Three

\n

Here is a video showing a user with Parkinson’s disease trying to scroll through such an interface during a user test we carried out a while ago. He speaks Swedish, so turn on the captions if you’re not one of the 10 million people who understands our fine language!

\n

\n

If you look closely, the user is trying to place his finger between the news stories. He’s hoping the space is unclickable, so that an accidental tap while trying to scroll will not activate a link. However, every part of the screen is linked. It\u2019s like the whole interface is one giant button \u2013 hey what a clever comparison, let\u2019s add that to the title of this article!

\n

Here’s a quote from the video that explains the essence of it:

\n

They should add some space between the different objects so that I can put my finger down without activating something.

\n

\u2013 User with Parkinson’s disease

\n

The simple solution

\n

It would help enormously if there was just a little bit of space between each touch target in the list. Like this:

\n

\"Space

\n

Now users can place their finger in that unclickable space and accidentally tap without flying off to another page. A little space between the touch targets also makes the interface feel less crowded. Win-win!

\n

This is how it looks on our site, scrolling through our\u00a0articles. Not too shabby, right?

\n

\"60

\n

Hey browsers! You can help out too

\n

Another way of solving this scroll-conundrum would be for browsers to make it possible to have a scrollbar visible at the side of the screen on mobile.

\n

\"Scrollbar

\n

The scrollbar could be activated through the browser\u2019s settings menu \u2013 or in some other smart way \u2013 so it doesn\u2019t have to show all the time for all users.

\n

But wait! Why isn\u2019t this in the accessibility guidelines?

\n

We don\u2019t know. The Web Content Accessibility Guidelines (WCAG) do not include this problem. We can only speculate as to why.\u00a0It might be because:

\n\n

Whatever the reason, the lack of focus on motor impairments in accessibility guidelines is a big problem that needs to be addressed. Hopefully the folks working with the 3.0 version of WCAG are listening!

\n

Also, this illustrates the point we make time after time: you need to user test with people with disabilities. No checklist or guideline will ever be able to replace meeting actual users and watching them use your product (tell us if you need help with this).

\n

Let’s make the web more hand tremor friendly

\n

Thanks for showing an interest in accessibility by reading this article. Hopefully you’ll help out in making the web a little more inclusive. Make sure there’s some unclickable space on each screen, it’s as simple as that!

\n

If you liked this article, here are some others you might enjoy:

\n\n

The post Hand tremors and the giant-button-problem appeared first on Axess Lab.

\n", "date_published": "2018-04-09T07:37:36+00:00", "date_modified": "2018-04-09T07:50:48+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/text-splitting/", "url": "https://axesslab.com/text-splitting/", "title": "Text Splitting Causes Screen Reader Problems", "content_html": "

I am a screen reader user, and I am annoyed! I repeatedly encounter the same problem on websites. It’s about text splitting up. Let me share my agony with you!

\n

\"Button

\n

The problem

\n

First a short background if you’re not familiar with screen readers. When navigating a web site on a touch screen, my screen reader \u2013 VoiceOver \u2013 will read what’s under my finger. It enables me and other people with visual impairments to use technology.

\n

What I should hear when touching a link with my finger is:

\n
    \n
  1. The name of the link.
  2. \n
  3. What type of element it is: “link”.
  4. \n
\n

For instance: “Contact information, link”.

\n

However, sometimes I just get to hear what type of element it is, not it’s name. Just “Link”. Not very helpful.

\n

The 16 second video below is from a Swedish site, but I think you’ll get the point even if you don’t know Swedish.

\n

\n

Notice how it just reads “Link” if my finger is on the right side of the elements \u2013 a bad user experience. If I touch the left side of the links, I get to hear the names together with the type of element \u2013 a good user experience.

\n

What’s going on here? Well, let’s take the last link in the example above. It’s made up of two parts: The name “Arkiv” and the link icon.

\n
<a href="...">\n   Arkiv \n   <span class="link-icon">\n   </span>\n</a>\n
\n

In the code, the icon is placed in its own span-element. A perfectly fine way to code your links. It should be read as one object, as the link-element is wrapping both the link name and the icon-span.

\n

But VoiceOver interprets it as two different objects if I touch the right span, rendering me confused.

\n

OK, so Apple should fix this?

\n

Yes, I wish. But I reported this error in 2012 and it’s still not fixed, so my hopes aren’t great. While we wait for Apple, there’s an easy workaround for developers to fix this on your sites.

\n

The solution: role=”text”

\n

We had a similar problem on our site with headings, but the solution I used will work for links as well. Let’s look at it.

\n

Here I’ve got an h1-element that looks like this in the code:

\n
<h1>Digital accessibility, <br>\nfor everyone.</h1>\n
\n

As you can see in the video below, the br-tag causes the screen reader to interpret the title as two separate objects, just like the span did in the previous example. I want it to read the whole heading to me at once.
\n

\n

So to force a screen reader to interpret the heading as one object, I wrapped the text inside the heading in a span and added role=”text”.

\n
<h1>\n   <span role="text">Digital accessibility, <br>\n      for everyone.\n   </span>\n</h1>\n
\n

And voil\u00e1, here is the result:
\n

\n

Beware! Don’t put role=”text” in the heading-element. This would erase the h1-semantics, so it would not appear as a heading in a screen reader. Every element inside the role=”text” will lose it’s semantics. So you need to add a span within the element and put role=”text” in that span.

\n

Apple, if you’re listening, please fix this. But until then, developers, please do the visual impaired community a favor and check your elements with a screen reader and fix them if necessary.

\n

Update \u2013 questions and answers

\n

This post went a bit viral! Which is great, but I’ve gotten a few questions that I want to clarify.

\n

Can’t we just use aria-hidden on the icon?

\n

Yes, we can, in some cases! In my first example, the link-icon is unnecessary to understand the purpose of the link, so you can just use aria-hidden=”true”. But we’d like the recommended technique to work in as many scenarios as possible.

\n

So imagine the following case. You have a link or heading with three words, where the middle one is stylized. For instance:

\n
<a href="...">Buy <strong>t-shirts</strong> now</a>\n
\n

Here, VoiceOver would announce them as separate links: “Buy link”, “t-shirts link”, “now link”.

\n

Now we can’t use aria-hidden since that would hide a word for the screen reader user. It would just say “Buy now link”, skipping the t-shirt part.

\n

However, using the role=”text” technique will work great in this scenario as well.

\n

Is this just a problem with explore by touch?

\n

To navigate with a screen reader you can either touch parts of the screen and have the objects you’re touching read to you \u2013 explore by touch \u2013 or swipe your way across the interface from object to object. I use explore by touch in my videos.

\n

One person asked if this problem only occurs if you explore by touch.

\n

However, sadly it happens both on explore by touch and when swiping.

\n

Why don’t you keep writing to Apple?

\n

Apple have actually answered me. They think this is a feature. It makes it possible to recognize that different words are styled in different ways.

\n

I think it’s a nice thought. But in reality, it’s not practical. For us screen reader users, it’s more important to get the whole sentence read than to recognize that something has a different styling.

\n

One idea would be to make the styling differences clear in some other way, like changing the pitch of the voice.

\n

The post Text Splitting Causes Screen Reader Problems appeared first on Axess Lab.

\n", "date_published": "2018-03-04T15:41:18+00:00", "date_modified": "2018-03-09T17:27:34+00:00", "author": { "name": "DanielGoransson" } }, { "id": "https://axesslab.com/switches/", "url": "https://axesslab.com/switches/", "title": "Assistive Technologies \u2013 The Switch", "content_html": "

A switch is an assistive technology primarily used by people with motor impairments to access and control computers, smartphones, electric wheelchairs, smart home appliances and more. Let’s look at some switches in action and go through how you design switch friendly interfaces.

\n

\"Two

\n

So what is a switch?

\n

At it’s core, a switch is simply a way for a user to activate a control. This can be done in multiple ways, and different users prefer different switches.

\n

The classic example of a switch looks like a big round button:

\n

\"Red

\n

This type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it.

\n

On the screen, there’s usually a focus indicator moving automatically across the different objects, and the user clicks by activating the switch. Some users have multiple switches and can use one to move the cursor forward and another for clicking.

\n

Video editor Christopher Hills has multiple switches placed on his head rest. Here’s a video where he shows how he uses his switches together with Apple Switch Control.

\n

\n

 

\n

World famous theoretical physicist Stephen Hawking used a handheld switch, or “clicker”, earlier in his life. But as his control of his hand muscles decreased due to his Amyotrophic lateral sclerosis (ALS), he now uses a “cheek-switch”. If you look closely, you can see it in the video below. It’s a black sensor just below his glasses. So he moves his cheek to activate the switch.

\n

\n

On Stephen’s screen, a focus cursor will move across his computer’s interface automatically, and he moves the cheeck-sensor to activate the object in focus.

\n

Most operating systems integrate with switches right out of the box, with no need to download special software or apps. For example, Apple devices have a setting called Switch Control (Settings, General, Accessiblity, Switch Control) and Android devices have Switch Access (Settings, Accessibility, Switch Access). You can use a Bluetooth keyboard with an iOS or Android device to try it out yourself. Or buy a switch, the cheapest ones cost around \u20ac 100.

\n

Another type of switch is a “Sip-and-puff”. In this case, the users activate the switch by either inhaling \u2013 sip \u2013 or exhaling \u2013 puff.

\n

Usually these types of switches come with a lip-controlled joystick that moves the mouse cursor on the screen.

\n

Here’s Mark Willits demonstrating how he uses a sip-and-puff switch Jouse in combination with voice recognition software and an on screen keyboard.

\n

\n

Here’s a similar product, Integramouse.

\n

\"Young

\n

Not only people with motor impairments use switches. Some people with intellectual or learning impairments can find keyboards or game controllers too complex. They use switches to play simple games, communicate using digital boards or quickly access their favorite sites.

\n

How to design switch-friendly interfaces

\n

Here are some things for developers and designers to think about when designing digital interfaces for switch users.

\n\n

There are \u2013 of course \u2013 more things to consider when creating switch accessible interfaces, but I think that is enough detail for this introductory article. Get in touch if you want a more complete checklist on switch accessibility: hello@axesslab.com!

\n

Hope you learned something new! Thanks for reading and leveling up your accessibility know-how!

\n

The post Assistive Technologies \u2013 The Switch appeared first on Axess Lab.

\n", "date_published": "2018-02-19T14:26:53+00:00", "date_modified": "2018-02-19T19:30:37+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/title-texts-suck/", "url": "https://axesslab.com/title-texts-suck/", "title": "Title Texts Suck", "content_html": "

Many people I meet think title texts, also known as tooltips, improve both the accessibility and usability of their sites. They don’t. In fact, they can even cause problems. Let’s see why!

\n

\"Hover

\n

What’s a title text?

\n

Here below is a link with a title text. Hold your mouse pointer over it for a while and a small text will pop up. That’s the title text. It’s added with the title-attribute in the link.

\n

Demo link with title

\n

This is how it looks:

\n

\"Mouse

\n

“Wait a minute” a lot of you will be thinking. “I’m on my phone, I don’t have a mouse pointer.” Great observation! It brings us perfectly onto our next topic…

\n

The problem with title texts

\n

1. Title texts don’t work on touch screens

\n

Title texts only show up on hover, and you can’t hover on 99.9% of all touch screens. I think most people would agree that a design pattern that doesn’t work on touchscreens kind of sucks.

\n

2.\u00a0Title texts cause problems for screen magnifiers

\n

For users with screen magnification, title texts will often be somewhat of a bully. The title text can be cut off the screen because the user is zoomed in so far. When the user moves the mouse pointer to be able to see it, the title text will often disappear. More on this in our article How to make your site accessible to screen magnifiers.

\"Screenshot

\n

Another problem for users with screen magnification is that the title text can cover essential parts of the content. In the example below the title text for the image covers the link below it.

\"Title

\n

You might be thinking: “Well, just move the mouse cursor.” Sadly it’s often not possible for users who are zoomed in very far and need to have the cursor where they are reading.

\n

As icing on top of the cake for this group of users, title texts will not be enlarged when you use browser zoom (control +). So yeah, title texts really suck for people with visual impairments.

\n

3. Title texts don’t work with keyboard navigation

\n

Apart from not working on touch screens, title texts don’t show up for users who navigate with the keyboard or with the many assistive technologies for users with motor impairments. There are ways to make the title text show on keyboard focus, but it’s not there by default and almost no developers will add that feature.

\n

4. Title texts require users to guess

\n

There is no way to tell if a link, icon, form field, button or other element has a title text before hovering over it. Most users will not bother to waste energy hovering over something to possibly get help. In the words of usability guru Jakob Nielsen: the interaction cost is too high.

\n

5. Title texts require users to wait

\n

Not only does the user have to guess if there’s a title text, they also have to wait a second before it possibly shows. Users are usually in a hurry when navigating the web, so most won’t stop and dwell.

\n

6. Screen readers read title texts inconsistently

\n

Many users with visual impairments use screen readers to navigate the web. Some screen readers will read title texts. Some will not the read title texts. Some will pause before reading them. Some have a setting that the user can enable to read them, but most will not know of that setting or bother activating it.

\n

The point is, title texts are handled differently and you can’t rely on how it’s conveyed to the user.

\n

Don’t trust me?

\n

David Ball of @silktide wrote this nicely researched piece on the same subject a few years ago:

\n

I thought title text improved accessibility. I was wrong.

\n

He asked html-expert Jeffrey Zeldman on his thoughts on title-texts.

\n
\n

@silktide No! Do not use.

\n

\u2014 zeldman (@zeldman) December 12, 2012

\n

\n

Web accessibility guru Bruce Lawson isn’t a fan of the title-text either:

\n
\n

@silktide kill it with fire. Or, as Bim, a blind screenreader user with RNIB would say: http://t.co/y6tN6UZU

\n

\u2014 Bruce Lawson (@brucel) December 12, 2012

\n

Also, here’s another nice article on title texts: Don’t rely on the title attribute for accessibility.

\n

What should I use instead of title texts?

\n

Well, just make sure your link and button names clearly describe where they take your user and you’ll be fine. Also, write text labels for your icons, then you’ll not need to worry about title texts.

\n

Don’t confuse title texts with alt-texts. Alt-texts are very important and don’t suck at all:

\n

Alt-texts: the Ultimate Guide

\n

What about iframes?

\n

Some accessibility experts say there’s one exception where they recommend using the title text: iframes. First off: don’t use iframes unless you really have to. They can really confuse screen reader users.

\n

But if you use them anyway, just add an aria-label that describes the iframe’s content instead of the title attribute and this conundrum is solved.

\n

Other things that suck

\n

This was our third article on the topic of things that suck. You should check out our other two master pieces:

\n

Disabled Buttons Suck

\n

Captchas Suck

\n

Hope you enjoyed!

\n

The post Title Texts Suck appeared first on Axess Lab.

\n", "date_published": "2018-02-08T15:15:51+00:00", "date_modified": "2018-02-13T16:37:51+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/paying-open-source/", "url": "https://axesslab.com/paying-open-source/", "title": "Paying Employees to Work on Open Source Projects", "content_html": "

Open source is awesome and even though we’re a startup we’ve found a way to pay our employees to contribute to the community. Here’s how and why we do it.

\n

\"Woman

\n

We, like most other companies that build software, base a lot of what we do on components and frameworks that were built in open source projects.

\n

Even though we are a small (but growing) startup \u2013 five employees at the moment \u2013 we wanted to find a way to actively contribute to the open source community. We were inspired by how Futurice sponsors free time open source activities, and set up our own version of it.

\n

The deal

\n

As an employee at Axess Lab, you get paid 15 \u20ac an hour for up to 10 hours a month for open source work if:

\n\n

The employees have a time code in our time reporting system where they report the open source work and add a copy to a relevant pull request or commit.

\n

That’s it. We don’t make it more complicated than that.

\n

What’s in it for us?

\n

Why would a startup like us do this. Well, we see many benefits:

\n\n

Want to know more?

\n

Hopefully this will inspire some other companies to set up something similar.

\n

If you want to know more, get in touch with us by mailing hello@axesslab.com or tweeting @axesslab.

\n

You’re extra welcome to message us if you live in Sweden and are interested in working with us to make the digital world more accessible!

\n

The post Paying Employees to Work on Open Source Projects appeared first on Axess Lab.

\n", "date_published": "2018-01-18T09:41:11+00:00", "date_modified": "2018-01-18T10:46:39+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/top-articles-2017/", "url": "https://axesslab.com/top-articles-2017/", "title": "Our Top Articles 2017", "content_html": "

It’s been a great 2017 at Axess Lab! We celebrate by listing our most popular articles all year.

\n

\"Podium
\n

The podium

\n

Here are the top three. Congratulations!

\n

Accessibility According to Actual People with Disabilities
\n🥇 43 000 page views
\n“If you have a disability, what’s the hardest thing about browsing the web?” We sum up the answers to a viral Twitter thread.

\n

How Icons are Ruining Interfaces
\n🥈 18 300 pageviews
\nMore and more designers are using icons in the wrong way. And it\u2019s hurting both the usability and accessibility of interfaces.

\n

Alt-texts: The Ultimate Guide
\n🥉 15 200 pageviews
\nPractical tips on how to craft the perfect alt-texts. We also go through when to \u2013 and not to \u2013 use them.

\n

Happy losers

\n

Here are some articles that fought hard but just missed the podium. Ouch!

\n

Disabled Buttons Suck
\nShowing buttons as disabled might seem like a good idea. It is not. Here\u2019s why disabled buttons suck and what to do instead.

\n

Fonts Don’t Matter
\nIf you\u2019re an art director, you might want to sit down for this. Here’s why fonts are overrated and what actually matters for readability.

\n

Top 7 Free Color Contrast Checkers
\nSeven great free tools that help you measure color contrasts and create beautiful, accessible color schemes

\n

The post Our Top Articles 2017 appeared first on Axess Lab.

\n", "date_published": "2017-12-29T12:01:13+00:00", "date_modified": "2017-12-29T12:01:13+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/practical-accessibility-improvements/", "url": "https://axesslab.com/practical-accessibility-improvements/", "title": "Practical Examples of Accessibility Improvements", "content_html": "

“It would be great to see actual examples of accessibility in action. Like before and after accessibility improvements.” I got this great comment from a woman in the audience at a meetup. So let’s make that idea a reality!

\n

\"Teddy

\n

Offer alternatives

\n

Accessibility is a lot about offering people alternatives.

\n

Here’s an example from “real life”. When I was user testing with people with disabilities, this slider proved to be an obstacle for people with motor impairments. It was difficult to set it to the specific value the users wanted to.

\"Slider

\n

We solved it by offering an alternative. Users can now either use the slider or input the numbers directly in the input fields.

\"Slider

\n

This turned out great for mobile users as well. Their fingers were previously covering the value under the slider as they were adjusting it. Now they could see it above the slider in the input fields as well. A win for everyone.

\n

Here are some other examples of offering alternatives to users:

\n

Instead of forcing people to call customer service, offer an alternative to write in a chat or email.

\"Call,

\n

Instead of forcing people to understand a diagram, offer an alternative to see the data in a table:

\"Diagram

\n

Instead of forcing people to read an article, offer an alternative to watch a video:

\"Video

\n

Note that it’s the combination of alternatives that’s the key. Not just a video or just text, but the combination of them. Let the user choose!

\n

Colors

\n

There are two main things to keep in mind when it comes to colors and accessibility: color contrasts and not relying solely on color.

\n

Color contrasts

\n

Good contrasts between text and background is important to make your content accessible to low vision users, or users who have sunlight reflecting off their screens.

\n

Here’s an example of light gray text on Squarespace that doesn’t fulfill the contrast guidelines in the Web Content Accessibility Guidelines (WCAG):

\n

\"Tiny,

\n

A normal contrast failure is for link colors. Mediatemple have links that are far from acceptable:

\n

\"Light

\n

To give you a feel for how little it takes to make your contrast sufficient, here is an example of failing contrasts for both the gray text and blue link, and an example of sufficient contrasts for the gray text and blue link.

\"Comparison

\n

You wouldn’t believe how hard I sometimes have to fight with art directors to get them to increase the contrasts to an acceptable level. Even though \u2013 in my view \u2013 everyone benefits and there’s not that big a difference aesthetically. Or is it just me?

\n

Anyway, it’s easy to measure contrasts yourself. Here are some free contrast checkers we recommend!

\n

Don’t rely solely on color

\n

Some people with color vision deficiencies can’t tell different colors apart.

\n

Here’s an example that would create problems:

\"Color
Simply labeling your colors is a way to make color pickers accessible:
\"Color

\n

A common fail to this criteria is links that are only blue:

\"Two

\n

Viewing this in grayscale makes it clear why this is important:

\"Previous

\n

Some ways to make your links pop out is underlining them, giving them link icons or making them look like buttons:

\"Links

\n

If you want to know more on this subject, check out our article on color blind accessibility.

\n

Keyboard accessibility

\n

Some users with motor impairments navigate using their keyboard. Many assistive technologies like switches, magnification and screen readers also rely on keyboard accessibility. But what does it mean to make your site or app keyboard accessible?

\n

Focus indication

\n

Make sure that it’s clear which element has focus when tabbing around in your interface.

\n

The default focus indicator varies between browsers, but it’s often not very easy to spot.

\n

\"Thin,

\n

Some sites, like Only.in, have even removed the default focus indicator. Most likely because someone googled how to remove it because they thought it looked ugly when focus was on their search field.

\n

\"Arrow

\n

On gov.uk focus is indicated with an orange background that really stands out from the surrounding:

\"Clear

\n

So design a clear focus indicator and implement it using the :focus selector in your css.

\n

Skip-links

\n

Skip-links are a bit magical! They don’t show up for most people, but if you navigate with a keyboard you’ll find them very helpful.

\n

They are made visible only when they receive focus and basically provide a shortcut past all the links in the site header and menus, so you quickly can get to the content of the page.

\n

Here’s a skip-link in action at www.starbucks.com.

\"Skip

\n

Try it out yourself by going to Starbucks and pressing the tab key on your keyboard until you see it (in any other browser than Safari, where keyboard navigation first needs to be activated in settings for some reason).

\n

Screen reader accessibility

\n

Making your site or app accessible for users with visual impairments who use screen readers is a lot about coding correctly and following the html-standard. For example: instead of building buttons and links out of spans, use the button and link elements.

\n

Another thing you need to do is add alt-texts to images, which conveys their meaning to people who can’t see them. Editors need to learn how to do this in their Content Managment System. It takes about 5 seconds for each image.

\"Alt-text
You should check out our Ultimate Guide to Alt-texts!

\n

Accessibility is a lot about simplicity and usability. Make your interface intuitive and use a clean layout and you’ll help all users, including screen reader users.

\n

Wrapping it up

\n

There is of course more to accessibility than I’ve listed above. But the point is that it’s not rocket science. Also, making your site or app accessible does not mean you have to make it boring and remove all colors, images and videos.

\n

Accessible sites can \u2013 and should \u2013 be made awesome and beautiful! If you want our help achieving this in your projects, let’s work together!

\n

Finally, I’d want to recommend the world’s best tumblr:

\n

a11ywins.tumblr.com

\n

It’s a collection of accessibility wins \u2013 that is, examples of awesome accessibility solutions on sites and apps. Jump over there and read it all!

\n

The post Practical Examples of Accessibility Improvements appeared first on Axess Lab.

\n", "date_published": "2017-12-28T16:33:08+00:00", "date_modified": "2017-12-29T11:32:55+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/users-no-disabilities/", "url": "https://axesslab.com/users-no-disabilities/", "title": "“Our Users Have no Disabilities”", "content_html": "

There are a lot of unfortunate misconceptions about people with disabilities. Many trickle down into IT-teams who use them as arguments not to care about accessibility. So it’s time to set some things straight!

\n

\"8

\n

Things we hear all the time

\n

When we at Axess Lab are out consulting or speaking about accessibility, time and time again we hear the same types of arguments from people who are not very keen on focusing on accessibility:

\n

I work on an intranet. We don’t have disabled employees.

\n

Our customers are athletes, not handicapped people.

\n

I’m building a site for this upcoming movie. Obviously, blind people are not part of my target audience.

\n

The many, many people who think or say these kinds of things probably don’t do it because they are pure evil! Instead, the comments are likely to stem from a lack of knowledge and preconceived ideas about disabilities.

\n

So, let’s bust some myths and straighten this thing out once and for all!

\n

All disabilities are not visible

\n

Most of the time, you can’t tell if a person has a disability just by looking at them. Even though you might not think you have colleagues or users with disabilities, you probably do. Here are some disabilities that usually are hidden:

\n\n

Even some disabilities that you think are visible are not always. I am legally blind. If I don’t chose to tell people, they usually have no idea. Just by looking at me, there’s no way to tell.

\n

Here I am, roller skating!
\n

\"Daniel

\n

So guess what! You’ll probably pass a lot of people today that have disabilities, but you won’t even notice!

\n

And me roller skating leads us nicely onto the next topic…

\n

People with disabilities have interests too

\n

There are a lot of preconceived ideas about what people with disabilities do. We do everything. Or nothing. Or exactly what we want to. And we want different things, just like everyone else.

\n

Some of my favorite interests are:

\n\n

I have friends who are blind. Some hate sports and don’t do video games. Some love them like me. I know people with hearing impairments that love music, theatre and musicals.

\n

The point is we are different and have many interests!

\n

This means that we buy soccer shoes, book movies tickets and hang out on video game review sites. And skateboards!

\n

\n

So let’s agree on that you can’t assume that their target audience has no disabilities. We are everywhere!

\n

Young people have disabilities too

\n

Many people tend to believe that disabilities is something that only elderly people have. It’s true that many disabilities are more common among the older population. But not all.

\n

Think of dyslexia, color vision deficiency, autism and adhd. They are just as common in all age groups. And there are, of course, young people with disabilities like vision and hearing impairments, even if they are more common among elderly.

\n

We would also like to congratulate you, our dear reader. You’ve just set a personal record! You’ve never been older than you are right now! And you’re getting older every day. Design for your future self!

\n

Employed people have disabilities too

\n

One of the most common situations where we hear excuses for not caring about accessibility is when it comes to intranets, administrative systems or any other system that is used by professionals. There is a widespread misconception that people with disabilities don’t work. At least not at your own office.

\n

This, of course, is false.

\n

People with disabilities can be found at any workplace. Sometimes you don’t know about it, because many disabilities are hidden. But trust me, we’re there!

\n

And even if you don’t have a colleague right now who is, say, blind, that doesn’t mean you can assume you never will.

\n

Let’s say a highly qualified individual is applying for a job. She’s better than all the competition and would be perfect for the position. However, she happens to use an assistive technology. And your intranet and administrative systems are not accessible at all. Because of that, she can’t do her job and you hire someone else.

\n

In that scenario, apart from the terrible discrimination, you also lose a great recruitment.

\n

So don’t just make your external website accessible. The inside counts as well!

\n

You can’t know your user’s environment

\n

Impairments can be situational. A user without a disability could be stressed, tired, drunk (maybe not for intranets..) or using their device in sunlight. Anyone could be riding the subway on a poor internet connection. All users have disabilities sometime in their day-to-day life.

\n

In web analytics, there is no good way of examining if the visitor has a disability or is using an assistive technology. So you can’t know if a user is using a screen reader or an eye tracker to navigate. So even if you know that over 90% of your users are using a large screen, you can’t assume that everyone is using a mouse. Which in turn means you can’t rely on hover to navigate.

\n

Tech enables

\n

Digital services like apps and web are often more important to people with disabilities than the so called average Joe out there.

\n

Let’s look at an example. Stephen Murray crashed on his BMX-bike and was paralyzed from the neck down. He now uses an eye tracker to control his technology. He runs his own company, pays his bills and communicates with friends and family, all by only using his eyes. Tech has enabled him to do all this, and to be independent again.

\n

\n

But Stephen Murray is also very reliant on the accessibility of the services that he uses. More so than most other people.

\n

Say you want to book a meeting room. If the booking system is a piece of paper by the meeting room, most people could use it, even if it would be a bit annoying not to be able to do it from the computer.

\n

Stephen wouldn’t be able to book it at all independently. The same goes for other people with disabilities, like someone in a wheelchair who might not reach the paper, someone with a hand tremor who can’t write with a pencil or someone with a vision impairment. An accessible digital booking solution is crucial fort these users, but benefits everyone.

\n

One last tip

\n

Now you’re hopefully equipped with enough arguments to convince your colleagues and bosses to prioritize accessibility. People with disabilities are everywhere and inclusive design is important for everyone. No matter what prject you’re in

\n

Here comes our last tip! The best way to get empathy and understanding from someone is to let them experience accessibility issues themselves. One way is to get\u00a0Funkify \u2013 the disability simulator, a free Chrome extension that we’ve been a part of building! Another way is to let us meet your team. We’ll let you use your site or apps with screen readers, magnification, eye control and a lot more. An empathy lab that will convince even your most stubborn colleague!

\n

Thanks for reading and keep on spreading accessibility awareness!

\n

The post “Our Users Have no Disabilities” appeared first on Axess Lab.

\n", "date_published": "2017-12-17T11:45:08+00:00", "date_modified": "2017-12-18T20:56:32+00:00", "author": { "name": "DanielGoransson" } }, { "id": "https://axesslab.com/app-accessibility-tips/", "url": "https://axesslab.com/app-accessibility-tips/", "title": "5 Ways to Make Your App More Accessible", "content_html": "

Users spend a large portion of their days in apps. However, there is not yet as much focus on app accessibility as web accessibility. It’s time to change that!

\n

\"iPhone

\n

This is a guest post by Bryn Gelbart from Fueled, who builds apps with accessibility in mind.

\n

Why care about app accessibility?

\n

One billion people, or about 15% of the world’s population, live with some form of disability. Combine that with the fact that smartphone and app usage is booming in all parts of the world, across all ages and abilities. This means that in order to truly maximize the impact, reach and profit of your mobile app you need to make sure it is easy to use for people of all ability sets. It must be accessible.

\n

An app can do this by addressing the core accessibility checklist that the Web Accessibility Initiative puts forward. But if you don’t have time to read through the long checklist, here are five practical ways to improve your app’s accessibility.

\n

1. Design for colorblindness

\n

Approximately 8% of \u00a0men and 0.5% of women are color blind according to visiontechnology.co. This comes close to 300 million people worldwide, a majority of those being caucasian men. That can be a bigger issue than you think considering the demographics of the tech industry.

\n

A core accessibility principle is to not rely solely on color to convey meaning. Don’t just make error messages red. Also add an error icon to make it clear to everyone.

\n

It is imperative to use easily distinguishable colors. Avoid mixing green and red, as that is the color combination that most people with color blindness can’t tell apart.

\n

You must make your backgrounds pop from your foregrounds, so no crucial information is lost on the color blind user. For example measure contrasts and make sure they comply with the color contrast threshold in WCAG (Web Content Accessibility Guidelines). Also, don’t have too similar hues of the same color, as this is likely to be seen as the same by many colorblind users.

\n

The screenshot from Candy Crush Saga below uses distinct shapes and varied shades to cater to colorblind users:

\n

\"Color

\n

2. Provide captions and alternative text

\n

Captions for video are essential for users with hearing impairments. Providing this alternative also benefits all users, as closed captioning can be useful in many situations, including commutes and while using your device in loud environments.

\n

Additionally, people who rely on text-to-speech voice technology are a demographic to consider when talking about accessibility. All photos and icons should have alternative text that can help all users get the full experience.

\n

To add this alternative description to images and icons in apps, refer to these guides provided by Google and Apple:

\n

Android Accessibility
\niOS Accessibility

\n

In short, for Android use android:contentDescription and for iOS use the label attribute.

\n

Another good guideline is to complement icons with text. That way, it’s more clear to everyone what the icon means. In the Remente app, each icon for feeling is complemented with a number from 1 to 5. Also, the thumbs up and thumbs down icons have a label “Negative” and “Positive”.

\n

\"Remente

\n

3. Readable and distinguishable interface

\n

Making sure displays on your app are easy to see goes beyond proofing for colorblindness. Giving your text a strong brightness-contrast and using larger font sizes is a good place to start.

\n

It is also important to differentiate clickable content. Hyperlinks and buttons that take the user to other screens should be both colored differently and highlighted with non-color characteristics, like a border on the button, a link underline or a link icon.

\n

Also, keep formatting consistent. Users with cognitive limitations may become confused if components are formatted differently on different pages.

\n

4. Be aware of seizure inducing elements

\n

According to stats from Healthline, about one in every 26 people will experience recurring seizures in their lifetime.\u00a0 The causes range from epilepsy to other less common conditions that can come into effect without prior warning or experience.

\n

Avoid putting in features that frequently flashes on the screen or makes use of the camera flash on devices. Alternating colors or patterns are a bad call as well. If these are features that you must include, provide a warning and an option to disable them.

\n

5. Multiple language settings

\n

While it does not fall into the same category as these other tips, it is important to recognize when your concept may be applicable to a non-English speaking audience. Translating all text is an easy way to expand your accessibility. On mobile these options will often be automatically changed based on user settings.

\n

An additional feature for multilingual users could be a slick drop down menu built into the interface that can give language options from within the app.

\n

Thanks Fueled

\n

It’s nice to see more and more companies spreading accessibility awareness! Thanks Fueled for writing this post. And no, we didn’t get paid to feature this. We just like working together with people who work with accessibility in mind!

\n

The post 5 Ways to Make Your App More Accessible appeared first on Axess Lab.

\n", "date_published": "2017-11-21T08:10:44+00:00", "date_modified": "2017-11-21T08:11:21+00:00", "author": { "name": "Guest" } }, { "id": "https://axesslab.com/iphone-x-onboarding-bug/", "url": "https://axesslab.com/iphone-x-onboarding-bug/", "title": "iPhone X \u2013 Welcome Screen Inaccessible to Blind Users", "content_html": "

I just got the new iPhone X. To my surprise, the first impression was not good at all for me as a user with a visual impairment. Apple usually don’t let me down, but now they seem to have made blunder.

\n

Explain what happened in text, please!

\n

Ok, so I use a screen reader that speaks information about the elements on the screen as I hold my finger over them.

\n

The first screen was totally blank to me, I got no information on how to proceed. Visually, there is text there, but I can’t see it and it’s not read with the screen reader. So it doesn’t help me.

\n

I couldn’t swipe across the screen to find elements to interact with, which I usually can.

\n

After struggling a while I found an element at the very bottom of the screen that said: “Home indicator, dimmed. Swipe one finger up from the bottom of the screen to go home”. I tried it even though I don’t want to go to the home screen, but it was the only thing I could do. That led me to the installation process.

\n

So I made it, but the experience was far from pleasant. I think many people with visual impairments will get stuck here and have to ask for sighted help, compromising their independence. Apple, hope you’re listening. Fix this please!

\n

The post iPhone X \u2013 Welcome Screen Inaccessible to Blind Users appeared first on Axess Lab.

\n", "date_published": "2017-11-17T13:25:05+00:00", "date_modified": "2017-11-17T13:30:15+00:00", "author": { "name": "DanielGoransson" } }, { "id": "https://axesslab.com/captchas-suck/", "url": "https://axesslab.com/captchas-suck/", "title": "Captchas Suck", "content_html": "

Captchas were invented to protect websites from spam. However, like the well-meaning invention of nuclear fusion, captchas too got some unethical and destructive side effects. Here’s why captchas suck and what to do instead.

\n

\"Captcha

\n

Introducing the evil

\n

Nobody likes captchas. They are at best an irritating, conversion-killing step users need to get past. At worst, they can be a complete roadblock to people.

\n

I’ll share my true feelings towards captchas at the end of this article in a poem. Yes \u2013 a poem. I’ve heard poems are good for expressing feelings. Anyway, first I’ll be more objective and describe what they are and why they do damage.

\n

Captchas are meant to tell humans and computers apart. The whacky name is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart.

\n

They come in some different shapes and forms. Here’s one that everyone would struggle with:

\n

\"Image

\n

Here is a captcha to sign up to a movie website, which \u2013 at least \u2013 is a bit whimsical!

\n

\"Captcha,

\n

Captchas are seriously inaccessible

\n

Imagine that you’ve spent what felt like an eternity filling out a form. Finally you get to the end of it and find this question.

\n

Prove you’re not a robot. Click on the animals in the image below.

\n

\"Abstract

\n

You can’t see any animals, but luckily you find a give-me-a-new-challenge-button. You click it:

\n

Prove you’re not a robot. Solve this simple math problem:

\n

\"Difficult

\nThese may be silly examples, but it’s a pretty accurate experience of how many people with disabilities experience captchas.

\n

For users who are blind or have visual impairments, these types of image-captchas are usually impossible to solve:

\n

\"Facebook

\n

For users with learning impairments, a math problem like 21+42 can feel like a complex integral:

\n

\"Math

\n

For users with dyslexia or other reading impairments, blurry images of squiggly text can be impossible to solve.

\n

\"Classic

\n

Users share their feelings

\n

Here are some users \u2013 with and without disabilities \u2013 expressing their not so loving feelings towards captchas on Twitter.

\n
\n

I just love when a site has a form of Captcha on there, and I already struggle to type the word (yay Dyslexia) AND IT'S CONTINUOUSLY WRONG. pic.twitter.com/twgXeG1puO

\n

— meg (@megsiobhan) March 13, 2017

\n

\n

https://twitter.com/krrnlyd/status/925985592160133120

\n
\n

@n5up I'm trying to contact you via web for ask a question but I can't 'cause I'm blind and I can't resolve the form CAPTCHA.Please help me

\n

— EA3GZA (Miguel) (@ea3gza) August 22, 2017

\n

\n
\n

As a person with dyslexia, I can say that captcha is really frustrating and annoying. #notarobot #justdyslexic

\n

— Lindsey Joyce (@thejoycean) January 22, 2017

\n

\n
\n

As to what drives her nuts, non-accessible captchas are the top. It can severely limit which services are available to her.

\n

— Danny Does Code (@DannyDoesCode) June 3, 2017

\n

\n
\n

Dear @Audible_com, introducing a CAPTCHA during iOS app login process is completely inaccessible and useless. #a11y

\n

— Pratik Patel (@ppatel) March 25, 2015

\n

\n
\n

Stupid captcha is blocking me from completing AWS registration!!! arghhh i hate captchas

\n

— Jos\u00e9 Rodrigues (@jrocharodrigues) October 23, 2017

\n

\n

No, Google’s new ReCAPTCHA is not good enough

\n

You might have come across the “I’m not a robot” captcha:

\n

\"Googles

\n

It’s not as bad as the standard captchas. But it’s still bad. People with assistive technologies like screen readers often report that they get classified as a bot and need to solve a regular, inaccessible captcha.

\n

Here is a video of a screen reader user trying to get past the captcha and failing. Get ready for some quick robotic speech. It can be hard to understand what’s going on if you’re not used to it.
\n

\n

Also, here’s a robot beating a captcha\u00a0😂

\n

\n

No, the audio alternative is not good enough

\n

Many captchas offer an audio alternative. Try listening to the next one you come across and you’ll understand why it’s not good enough. It can be really, really hard to hear the message, since it’s got to be distorted enough that computers can’t figure it out.

\n

Another problem with the audio captcha\u00a0is that the icon to switch to the audio captcha\u00a0is usually really small and difficult to find. Screen reader users also tend to struggle as the audio starts playing before they’ve found the field for inputting the text. Focus should be put on the field automatically, but usually isn’t.

\n

A few years back, the White House had a CAPTCHA that prevented blind people to sign a petition for an international treaty that was supposed to help the blind. Here’s what they had to say about the audio captcha:

\n

An audio code option \u2014 meant to help the blind complete the Captcha \u2014 is incomprehensible, according federation spokesman Chris Danielsen. And that same flawed audio code system is in use for people who wish to write the White House an email with any suggestions or complaints regarding the \u201cWe The People\u201d site.

\n

Captchas hurt conversions

\n

So captchas exclude many users with disabilities. This should be the only reason you need to seriously question their existence. But let’s look at another serious problem: it’s a conversion rate killer.

\n

Everyone struggle with captchas, not just people with disabilities. Many have conducted A/B tests and shown how they hurt conversion rates.

\n

Webnographer conducted an online usability test where only 62 percent of users completed Captcha on their first try. 23 percent gamely struggled through multiple attempts before succeeding, but 15 percent gave up entirely.
\n\u2013 Do the new Captchas Affect Conversion Rates (pagewiz.com)

\n

They ran the test until 99% confidence level was achieved. The form with a captcha converted at 48% whilst without it converted at 64%. A 33% increase in conversions!
\n\u2013 Web form optimization (acquireconvert.com)

\n

So \u2013 not surprisingly \u2013 captchas will lower your conversions. That \u2013 to most organisations \u2013 means less revenue. Another awesome reason to seriously question captchas.

\n

What to do instead

\n

Throw it out

\n

The first thing you should consider is to just not have a captcha.

\n

Sifting through SPAM is irritating and time-consuming, but it\u2019s better to get more SPAM and conversions than not to.
\n\u2013 Why Your Captcha is Killing Your Conversions (medium.com)

\n

Having an accessible site with high conversion rate might be worth the spam.

\n

Also, there’s something iffy and unprofessional about web site owners putting the burden of their spam problems on their users. Solve it “on your side” instead.

\n

Don\u2019t make users take responsibility for our problems.
\n\u2013 Beyond Captcha (sitepoint.com)

\n

Replace the captcha with an accessible alternatives

\n

There are ways to verify your users without using a captcha. Here’s one example that allows users to skip the captcha:

\n

\"Checkbox

\n

Check out these articles on Captcha alternatives:

\n

9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)

\n

Not all of the 9 methods are accessible, so focus your attention on number 3 \u2013 “Biometric security”, number 4 \u2013 “Text message verification” and number 6 \u2013 “The honeypot method”.

\n

Think Your Site Needs A CAPTCHA? (usertesting.com)\u00a0

\n

Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.

\n

A final poem to captchas

\n

So here’s what I promised at the beginning of the article. Be advised, I haven’t written a poem since I was in the eight grade.

\n

But I feel it’s time. I’ve got some strong feelings I need to express. No it doesn’t rhyme. And excuse the harsh language.

\n

Anyway, here goes!

\n

Dear captcha.

\n

They say everyone is good inside.
\nBut you are pure evil.
\nThe dark side of cyberspace.
\nThe Voldemort of the web.

\n

<In the next section I\u2019ll substitute a bad word with \u201dduck\u201d>

\n

So duck you, captcha.
\nDuck\u00a0your squiggly faded tilted letters.
\nDuck you for making users squint and curse.
\nDuck you for excluding users with disabilities.

\n

You inaccessible, abelist piece of sh….shoe.
\nA blocker to people with vision, reading or learning impairments.
\nYou are to accessibility what cigarettes are to lungs.
\nYou are technological discrimination

\n

To be fair, you’ve made one accomplishment.
\nYou improve spam robots’ letter recognition.
\nMaybe one day that can be used for something.
\nOther than ducking up people’s life.

\n

Developers, web designers, user experience professionals.
\nYou’re smart, creative, empathetic people.
\nGoogle “captcha alternatives”. Start questioning them.
\nYou can do better than a captcha.

\n

The post Captchas Suck appeared first on Axess Lab.

\n", "date_published": "2017-11-02T16:01:07+00:00", "date_modified": "2018-02-12T14:51:39+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/trends/", "url": "https://axesslab.com/trends/", "title": "Trends That Exclude", "content_html": "

Jumping on a new trend is risky business, both in fashion and web design! Here is why trends often hurt the user experience and exclude users with disabilities. I’ll also go through what you can do to avoid this from happening.

\n

\"Six

\n

Trend #1: Bright and light

\n

For a while now, it’s been considered modern to design things that are difficult to see. It’s a strange trend that’s causing problems for all sorts of users. Let me walk you through some troublesome bright and light trends out there.

\n

Thin, small, grey font\u00a0💩

\n

Slim, tiny, grey letters are popping up in interfaces all over the web, forcing users to strain their eyes while reading. Companies like Squarespace are even winning awards for this kind of unsightly design:

\n

\"Tiny,

\n

Running this interface through the disability simulator Funkify, this is what the interface above looks like with blurry vision:

\n

\"Blurry

\n

Not very pleasant, right?

\n

Nobody likes to strain their eyes when reading, but this trend is especially hurtful to some user groups:

\n\n

When asked what causes accessibility problems on the web (our full article: Accessibility According to Actual Users with Disabilities), quite a few people brought up this topic:

\n
\n

Nearly blind in my left eye. Tiny, thin font with low contrast to the background

\n

\u2014 \u26a1\ufe0fAndrew So\u26a1\ufe0f (@AndrewDixonSo) 3 juni 2017

\n

\n

I know what you’re thinking: It’s Apple’s fault!

\n

Yes, Apple introduced a thin font in iOS a couple of years back and they used grey text color a lot in their designs. However, they made sure the grey had a sufficient contrast level (how to check color contrasts) and the thin font wasn’t measured in nanometers.

\n

The problem was that when other designers jumped on this trend, they made the grey color brighter and the letters thinner. Suddenly the text was only readable by designers with 52 inch retina displays and predator birds.

\n

That’s why it’s so nice to hear that Apple is ditching it’s thin, grey fonts. Here’s a comparison between the old and new phone interface:

\n

\"iPhone
So Apple is moving away from the thin, grey trend. You should too.

\n

Bright color schemes\u00a0💩

\n

Many users with disabilities struggle on the web because of contrast issues in trendy interfaces.

\n
\n

Lack of contrast between font color and background color. Photo backgrounds that overpower the text on top of them.

\n

\u2014 Megan Lynch (@may_gun) 4 juni 2017

\n


\nOne common offender is white text on brightly colored backgrounds:

\n

\"White

\n

The color contrasts between the text and backgrounds above are terrible and far below the accepted contrast level in the Web Content Accessibility Guidelines (WCAG).

\n

Like the tweet above said, another common contrast problem is when text is placed right on top of images, which is trendy now.

\n

\"White

\n

So start measuring contrasts and make your content easy to read for all your users.

\n

Ghost buttons\u00a0💩

\n

Ghost buttons\u00a0are transparent,\u00a0thin buttons that have become popular lately. Like the name suggests, it’s quite a frightening design trend!

\n

The background overpowers the important content, making the buttons harder to spot and read:

\n

\"Transparent

\n

Make buttons stand out. It improves usability, conversions and accessibility. I think it’s time to stop scaring users away with ghost buttons.

\n

Trend #2: Motion

\n

Motion in interfaces is one of the top things that causes frustration when user testing with people with disabilities. It’s extra irritating for some people with cognitive disabilities, like adhd and autism.

\n
\n

ADHD: If there’s a \u201csubtle\u201d animation always running, I cannot focus. Biggest offender: https://t.co/KgfCA4a7lB‘s header gradient

\n

\u2014 Taylor Hunt (@tigt_) 3 juni 2017

\n

\n
\n

Assuming ADHD counts, it’s hard to locate content on overly busy pages and animations are a nightmare of distraction. #clickthemonkey

\n

\u2014 mkb (@mojinations) 4 juni 2017

\n

\n
\n

related, I’m also autistic and can get frustrated with, or repelled by, glitzy mouseover effects/animations, sudden autoplay, etc.

\n

\u2014 back at the holler (@elementnumber46) 3 juni 2017

\n

\n

Let’s look closer at two motion trends that are annoying users: parallax scroll and image carousels.

\n

Parallax scroll\u00a0💩💩

\n

Parallax scroll is a technique that became popular recently. To highlight how terrible this design trend is, I give it two poop-emojis instead of just one.

\n

Don’t you just love coming to a site to realize they’ve hijacked your scroll wheel? So that when you scroll, strange things happen on the site.

\n

You’re not alone in thinking that’s frustrating!

\n

Here’s an example where animations start cluttering the interface as the user scrolls:

\n
\n
\n

It might look cool at a glance, but after a few seconds it gets really annoying. Not many users like it and some even get seasick, especially people with balance disorders.

\n

Try the madness yourself at parall.ax.

\n

Image carousels\u00a0💩

\n

Image carousels is another motion trend you should avoid, and something that the user experience (UX) community has warned about for years. Sadly, there are still plenty of sites that use them, creating distractions for users who are trying to focus on reading the site’s content.

\n

\"Carousel

\n

Why are carousels bad? I’ll let my favorite site on the web tell you the answer: shouldiuseacarousel.com.

\n

Trend #3: Inaccessible social media posts

\n

In feeds all across social media platforms, we’re seeing posts that exclude users with low vision or reading impairments. Let me take two examples.

\n

Images of text\u00a0💩

\n

“Hahaha check out this epic meme:”

\n

\"Facebook

\nHilarious, right?\u00a0Didn’t think so.\u00a0The image is a meme that contains text, which will not be read by assistive technologies. So this is the experience many users with disabilities will get.

\n

Some social media platforms like Facebook will automatically describe what images might contain (like TV and dog indoors) to users with visual impairments who can’t see the image. But this description will not include the text in the image. So if you post an image of text, you should describe the text in the actual post.

\n

Let’s try it again:

\n

“Hahaha check out this epic meme! Making my dog watch commercials of the homeless dogs so he knows how good he got it.”

\n

\"Facebook

\n

Much better right? And more along the lines of the experience a sighted user has:

\n

\"Meme

\n

The text description will also help users with reading impairments who use assistive technologies to read text. These assistive technologies will not be able to read image of text, so writing the text in the actual post is very helpful.

\n

If you’re interested in learning more about accessible images in social media, check out this article on accessible social media posting.

\n

Videos with text only\u00a0💩

\n

An awesome trend that has started on social media is captioning videos. Facebook autoplays videos in your feed, and 85% watch videos without turning the sound on. So people have started captioning, which is great for everyone but crucial for hard-of-hearing or deaf users.

\n

However, lately this nice trend has shifted a bit too far. Now many skip the soundtrack altogether and only write text in videos.

\n

Here’s an example, in Swedish but you get the point:

\n
\n

This excludes users who have a severe sight or reading impairment who depend on a voice narrating the video.

\n

So don’t just use text on videos. And don’t just use sound. Sound and text in videos are like pancakes and jam \u2013 awesome together!

\n

Trend #4: Icons only\u00a0💩

\n

Icons without text labels have blossomed with the rise of smartphones. There is a major shortage of screen space on small devices, so the idea of replacing text with icons is obviously an attractive one.

\n

\"Lots

\n

However, icons without text labels require users to do a lot of thinking and it’s causing significant usability problems. I wrote a whole article on that topic:\u00a0How Icons are Ruining Interfaces.

\n

Apart from usability problems, the icons often cause specific problems for assistive technologies. When there is no text label, a screen reader user is dependant on the presence of a description of the icon in the code. This is not difficult to do for a developer, but many, many, many forget it. Then the screen reader will say something along the lines of: “Button 3” instead of “Button Play clip”.

\n

A young girl with a vision impairment I interviewed a while back told me about how her favourite app had updated, and suddenly there were no descriptions of any of the buttons. She had to get sighted help and memorise patterns to be able to using it:

\n

To start I press button 3, then 7, then 2. I change track on button 11. It’s difficult to find but I’ve gotten quite good at it!
\n– Screen reader user

\n

Not a very nice user experience, right? So the icons-without-text-labels-trend is causing problems for all sorts of users.

\n

Why, oh why, does this happen?

\n

Here’s my theory as to why so many new trends exclude users.

\n

Go to Google Images and search for “web designers”. You’ll get a lot of results like this one:

\n

\"Google

\n

Young people sitting in front of giant monitors designing. This is how it looks in many tech offices around the world. Of course these people are not likely to react to problems with color contrasts or thin letters.

\n

Almost anything looks good on such an expensive screen!\u00a0However, the users’ reality is often a lot different.

\n

Most designers and their colleagues are also very much more tech-savvy than the average person out there. Designers will often find new tech trends interesting, while most users just want interfaces to look and work like they’re used to.

\n

What should we do about it?

\n

Glad you asked! Here are my three best tips on reducing the excluding-trends-problem.

\n

1. User test with a wider audience

\n

I assume you already user test your interfaces. Otherwise start right away! But either way, make sure you recrute a wide range of users to your tests, for example:

\n\n

User testing with these user groups is extra important when you’re considering jumping on a new trend, to spot potential accessibility issues. If you make sure your interface works well for these users, you’ll also make it easier to use for everyone. Win-win!

\n

2. Train your team

\n

The best way to create inclusive products is to educate yourself and your team on the topic of accessibility. Take a course and learn to see things from new perspectives. Make sure your developers know the techniques for coding accessibility into their interfaces, designers know how to check for contrasts and testers know the basics of using some assistive technologies. Accessibility is not a one man show, it’s a team effort!

\n

3. Test with Funkify

\n

We’ve created a free browser plugin, Funkify, that let’s you simulate different disabilities, right on your site. View your site through a blurry filter, \u00a0try navigating with a trembling mouse pointer and more. It can help you evaluate your interface in your day to day work!

\n

Here’s a demo of the plugin in action:

\n
\n

That’s all, folks!

\n

Let’s work together to embrace inclusive trends that make the digital world a better place for all users!

\n

The post Trends That Exclude appeared first on Axess Lab.

\n", "date_published": "2017-10-18T12:04:41+00:00", "date_modified": "2017-10-27T07:33:03+00:00", "author": { "name": "Hampus Sethfors" }, "attachments": [ { "url": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/10/parallax2.mp4", "mime_type": "video/mp4", "size_in_bytes": 2585217 } ] }, { "id": "https://axesslab.com/alt-texts/", "url": "https://axesslab.com/alt-texts/", "title": "Alt-texts: The Ultimate Guide", "content_html": "

This post contains everything you need to know about alt-texts! When to use them and how to perfectly craft them. By me, Daniel, a web developer with vision impairment who use a screen reader in my day-to-day life.

\n

\"Cat

\n

My experience of images on the web

\n

I use a combination of magnification and screen reader when surfing the web. As a rule of thumb, I use magnification on larger screens and a screen reader on smaller devices.

\n

I, like everyone else, come across many images when surfing the web. If I’m using a screen reader I depend on getting a description of the image \u2013 the alt-text \u2013 read to me.

\n

Many times the alt-text is not helpful, often even a waste of my time because it doesn’t convey any meaning.

\n

Let me illustrate this on The Verge’s startpage. This is what it looks like for sighted people:

\n

\"News

\n

Below is what I see. I’ve replaced the images with what my screen reader reads:

\n

\"Strange

\n

Not very useful, huh?

\n

Here are some common alt-text-fails I come across:

\n\n

Alt-texts are not always this bad, but there’s usually a lot to improve upon. So whether you are a complete beginner or want to take your “game” to the next level, here’s our ultimate guide to alt-texts!

\n

What is an alt-text

\n

An alt-text is a description of an image that’s shown to people who for some reason can’t see the image. Among others, alt-texts help:

\n\n

The first group \u2013 people with little or no vision \u2013 is arguably the one that benefits most from alt-texts. They use something called a screen reader to navigate the web. A screen reader transforms visual information to speech or braille. To do this accurately, your website’s images need to have alt-texts.

\n

Alt-texts are super important! So important that the Web Content Accessibility Guidelines (WCAG) have alt-texts as their very first guideline:

\n

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
\n\u2013 WCAG guideline 1.1.1

\n

How do I add an alt-text?

\n

In html, an alt-text is an attribute in an image element:

\n

HTML

\n
<img src="dog.png" alt="Dog playing in meadow." />
\n

Most content management systems (CMS), like WordPress, let you create the alt-text when you upload an image:

\n

\"\"

\n

The field is usually named “Alt-text”, “Alternative text” or “Alt”, but in some interfaces it’s called “Image description” or something similar.

\n

Let’s create the perfect alt-text!

\n

Here are the steps to crafting fabulous alt-texts!

\n

Describe the image

\n

It might sound obvious, but an alt-text should describe the image. For example:
\n“Group of people on a train station.”
\n“Happy baby playing in a sand box.”
\n“Five people in line at a supermarket.”

\n

Things that do not belong in an alt-text are:

\n\n

Content of the alt-text depends on context

\n

How you describe the image depends on its context. Let me give you an example:

\n

\"Middle

\n

If this image was featured in an article about photography, the alt-text could be something along the lines of:

\n

“Close up, greyscale photograph of man outside, face in focus, unfocused background.”

\n

If the image is on a website about a TV-series, an appropriate alt-text could be completely different:

\n

“Star of the show, Adam Lee, looking strained outside in the rain.”

\n

So write an alt-text that is as meaningful as possible for the user in the context they’re in.

\n

Keep it concise

\n

Reading the previous section, you might be thinking to yourself: “I, as a sighted user, can see many details in the image, like who it is, how it’s photographed, type of jacket, approximate age of the guy and more. Why not write a detailed, long alt-text so a user with visual impairment gets as much information as I do?”

\n

Glad you asked!

\n

Well frankly, you can also get the necessary information from the image at a glance, and that’s what we’re trying to achieve for users with screen readers as well. Give the necessary information in the alt-text, but make it as short and concise as possible.

\n

One of the few times you should write long alt-texts is when you’re describing an image containing important text. Ideally, you should not have images of text, but sometimes you need to. Like on some screenshots or photos of signs.

\n

But the general rule of thumb is to keep it concise and avoid a verbose experience.

\n

Don’t say it’s an image

\n

Don’t start alt-texts with “Image of”, “Photo of” or similar. The screen reader will add that by default. So if you write “Image of” in an alt-text, a screen reader will say “Image Image of…” when the user focuses on the image. Not very pleasant.

\n

One thing you can do is end the alt-text by stating if it’s a special type of image, like an illustration.

\n

“Dog jumping through a hoop. Illustration.”

\n

End with a period.

\n

End the alt-text with a period. This will make screen readers pause a bit after the last word in the alt-text, which creates a more pleasant reading experience for the user.

\n

Don’t use the title-attribute

\n

Many interfaces have a field for adding title-texts to images close to where you can add an alt-text. Skip the title text! Nobody uses them \u2013 they don’t work on touch screens and on desktop they require that the user hovers for a while over an image, which nobody does. Also, adding a title-text makes some screen readers both read the title-text and the alt-text, which becomes redundant. So just don’t add a title-text.

\n

When not to use an alt-text

\n

In most cases you should use an alt-text for images, but there are some exceptions where you should leave the alt-text blank. Important note: never remove the alt-attribute, that would mean breaking the html-standard. But you are allowed to set it to an empty string, that is: alt=””. Do that in the following cases.

\n

Repeated images in feeds

\n

Pretend you’re scrolling through your Twitter feed. Everytime you want to read a new tweet, you first have to listen to “Profile picture of user <username of the person who posted>”. In my opinion, that would be super annoying!

\n

Other examples of feeds are:

\n\n

So for an ideal user experience, leave the alt-text blank for images that are used repeatedly in feeds.

\n

Icons with text labels

\n

You should always have text labels next to icons. Assuming you do, the icon should not have an alt-text. Let me explain why!

\n

Let’s take a social media button as an example:

\n

\"Facebook

\n

If you would write an alt text to the Facebook icon, a screen reader would say something along the line: “Facebook Facebook.” Very redundant!

\n

OK, this is technically not about alt-texts but still important: make sure both the icon and the link text are in the same link-attribute, to get a smooth experience. Like this:
\nHTML

\n
<a href="...">\n  <img src="fb_icon.png" alt="" />\n  Facebook\n</a>
\n

Another common mistake with icons is on menu buttons:

\n

\"Menu

\n

If the menu button has no visual text label \u2013 which, by the way, is really bad for the user experience \u2013 then it needs an alt-text (or another way of describing its function in code, like aria-label). Explain the icon’s function, like “Menu”. Don’t write “Three horizontal lines” or “Main hamburger”, which sadly are real examples I’ve stumbled on.

\n

If the menu icon has a label, you should leave the alt-text blank. I often find menu buttons which are read as “Menu menu”. Once I even came across “Hamburger menu menu”. Somewhat confusing wouldn’t you say?

\n

Images in links

\n

Usually an image within a link is accompanied by a link text. Like in the example below:

\n

\"Image

\n

In this case, the image and the link should be in the same link-tag in the html. In this case, you can just leave the alt-text blank. The important thing for the user is to hear the link text. An alt-text of the image would only distract by adding information that the user will not find necessary. The image is probably found on the page that is linked, and then you can give a good explanation of it in the alt-text.

\n

If you really, really have to have an image in a link without an accompanying text, then the alt-text should describe the link destination, not the image.

\n

Decorative images

\n

Preferably, decorative images that do not convey any meaning to the user should be placed as background images in css. It probably goes without saying, but this means you don’t need alt-texts on them at all.

\n

I’d classify most images that you place text on as decorative. You don’t need an alt-text on them. One example is the background image on Netflix’s startpage:
\n

\"Netflix

\n

Special cases

\n

Logos in the banner

\n

Logos in the banner almost always link to the websites start page. The opinions vary a bit on the topic of alt-texts for logos.

\n

Some say it should include the company name, the fact that it is a logo and the destination of the link. Like such:

\n

“Axess Lab, logotype, go to start page.”

\n

In my opinion, this is a bit verbose. Too much noise! Since my screen reader already tells me it’s an image and a link, I only feel I need to hear the company name. From the fact it’s an image I assume it’s a logo and from the fact it’s a link I assume it follow conventions and links to the start page.

\n

Svg

\n

Scalable vector graphics (svg) is an image format that’s becoming more and more popular on the web. And I love them! They keep their sharpness while zooming and take up less space so websites load faster.

\n

There are a two main ways of adding an svg to an html-page.

\n
    \n
  1. Inside an img-element. In that case, just add an alt-text as usual:
    \nHTML

    \n
    <img src="dog.svg" alt="Dog rolling on gras." />
    \n
  2. \n
  3. Using an svg-tag. If you use this method, you can’t add an alt-attribute because there’s no support for that. However you can get around this by adding two wai-aria attributes: role=”img” and aria-label=”<the alt-text>.
  4. \n
\n

Actually, for the second case, you’re supposed to be able to add your alt-text as a title-element in the svg, but there is not enough support for that from browsers and assistive technologies at the moment.

\n

Can’t a machine do this for me?

\n

Although machine learning and artificial intelligence is improving quickly and can describe some images quite accurately, they are not good enough at understanding the relevant context at the moment. On top of that, machines are not good enough at deciding what is “concise”, and will often describe too much or too little of the image.

\n

Facebook has actually built in a feature that describes images automatically. But I feel like the descriptions are usually too general. One image in my feed right now is described as: “Cat indoors”. The actual photo shows a cat hunting a toy mouse.

\n

So I’m sorry, you still have to write alt-texts yourself!

\n

Thanks for making the web better!

\n

I’m happy you read this far! It means you care about making the web a better place for all users. Spread the knowledge and keep being awesome!

\n

The post Alt-texts: The Ultimate Guide appeared first on Axess Lab.

\n", "date_published": "2017-10-15T16:44:25+00:00", "date_modified": "2017-10-16T11:02:54+00:00", "author": { "name": "DanielGoransson" } }, { "id": "https://axesslab.com/charm/", "url": "https://axesslab.com/charm/", "title": "Charming interfaces \u2013 make your users smile", "content_html": "

Using charm and humor in interfaces is a hugely underestimated technique that can make the user experience delightful, memorable and sharable. Here’s how to design, write and illustrate your way to smiling users!

\n

\"Young

\n

Hey…aren’t you accessibility experts?

\n

Yes, at Axess Lab we specialize in accessibility.

\n

But what does this post have to do with accessibility? Are you really allowed to use humor around people with disabilities?

\n

Well, I’ve carried out some rigorous research and it turns out people with disabilities actually enjoy having fun!

\n

Also, since technology is usually full of frustrating accessibility issues, I’d argue that people with disabilities benefit more from charismatic interfaces than most users.

\n

The polite registration form

\n

In this article I’ll give you a bunch of examples of charming interfaces, talk about the benefits of using humor and give tips on how you can succeed. But first, a short anecdote on how I stumbled on this topic.

\n

A few years ago, I was stuck at a login screen, trying a gazillion different email-password-combinations. My frustration grew for every incorrect-email-or-password-message I got thrown at me. You probably know the feeling.

\n

I finally gave up, cursed and went to their registration screen to set up a new account. I was in a terrible mood.

\n

I typed my first name in the registration form. A message popped up to the right of the field:

\n

\""Nice

\n

“Nice to meet you!” It caught me off guard, got me smirking and made me curious. I quickly moved to the field for last name. Another reply from the form:

\n

“Great name!”

\n

Probably the first complement I had got all week! It. Felt. Great!

\n

I was probably humming Lego The Movie’s themesong “Everything is awesome” as I finished the last two fields.

\n

\"Complements
New delightful messages at each field. In less than a minute a form had turned my mood from “please kill me” to “I’m the king of the world!” For the first time ever I felt sad that I was done with an online form!

\n

How to use humor in interfaces

\n

This experience got me thinking about how we can use charm and humor to enhance the user experience. I started collecting examples of interfaces that do it well. It’s an underused technique, so it’s quite hard to find good examples, but I’ve been searching for a long time!

\n

So now I’d like to share what I’ve found and hopefully inspire some of you to work on making your users smile.

\n

I’ll give examples on three ways to use humor in interfaces:

\n
    \n
  1. Make errors less frustrating
  2. \n
  3. Make users smile at details
  4. \n
  5. Convince users to do something they don’t really want to
  6. \n
\n

Let’s dive in!

\n

Make errors less frustrating

\n

One great place to start experimenting with charm is in error messages. Try to make your users smile with an illustration or unexpected wording. If you succeed, it will make your users more forgiving and they’ll hopefully find the energy to get around the error.

\n

Twitter shows an adorable illustration when it’s down due to overload:

\n

\"Error

\n

Google also uses funny illustrations if there are no results when searching for flights:

\n

\"Illustration

\n

Spotify cleverly complements the user instead of just saying “There are no lyrics available for that song”:

\n

\"Error

\n

Mailchimp hints of an evil twin if the username you want is taken:

\n

\"That

\n

Basecamp has an illustrated boy pointing to each form field as you fill them in. He turns surprised when you make a mistake:

\n

\"Guy

\n

A 404-page is an awesome place to add some humor. Olivia Ricci exploits every user’s strong feelings for cute kittens. Aww!

\n

\"404

\n

Why do charming error messages works wonders?

\n

Well, users will likely be irritated when they see the error. Luckily, it’s close to impossible to stay angry when you’re looking at a cute kitten.

\n

If you’re interested in the science behind it: smiling and laughing releases dopamine, endorphins and serotonin which acts as mood-lifter and makes you relaxed and feel less pain. You’re basically drugging your users when they need it the most!

\n

Make users smile at details

\n

Another great place to use humor is in the details. Leave small treats for your users!

\n

There is a great site dedicated to this: Little Big Details. If you find this article interesting, you should definitely check it out. I got quite a few of my examples from it.

\n

In Spotify the time bar turns into a light saber in the Darth Vader playlist:

\n

\"Spotify.

\n

Google Hangouts show charming animations when you type certain words, like “Happy new year”:

\n

\"User

\n

Tumblr changes their wording depending on the age of the user:

\n

\"Tumblr

\n

A Lego figure covers his eyes when you type your password on Lego Universe:

\n

\"Lego

\n

Siri answers some philosophical questions in clever ways:

\n

\"Siri.

\n

Generally, you should not ask users for their gender if you really don’t need that information. But assuming you do, you can add some humor:

\n

\"Gender

\n

Mailchimp shows a high-fiving chimp hand when you’ve shipped an email campaign. Clicking it \u2013 or high-fiving it back \u2013 makes the hand gradually more red.

\n

\"Mailchimp.

\n

If you continue to click the hand, a high-five game starts in your browser. It made me wonder if Mailchimp’s developers have a bit too much time to spare…Or hey! Maybe they prioritize this type of content because they know it works!

\n

\"Game

\n

Here are some advantages of using humor in the details:

\n\n

Convince users to do something they don’t really want to

\n

Increase conversion rates by manipulating with charm! It might sound a bit odd, but you can use humor as an energy-boost for carrying out tasks that users might not feel like doing.

\n

Songkick charms their users by offering something silly if they track 20 artists. Who wouldn’t put down the effort just to see the drawn picture they offer?!

\n

\"Dialogue

\n

Nobody likes to wait, but as the old saying goes: “Time flies when you’re having fun”. There are some charming progress bars and loading spinners out there. Here’s a nice one by Dennis Perepelenko:

\n

\"Loading

\n

OkCupid shows this epic banner to people who use ad-blockers to get them to donate.

\n

\"Banner

\n

You will be much more inclined to do something if you’re in a good mood! That’s the simple brilliance behind this technique!

\n

Still skeptical?

\n

“I see your point, but I can’t design whimsical interfaces because I run a professional/business-to-business/multi-million-dollar/fortune 500/<insert\u00a0 your excuse here> company.”

\n

I understand your concern, but \u2013 at the risk of sounding like a polite Englishman \u2013 I beg to differ. People don’t stop liking humor just because they go to work or become rich CEO’s. It’s human nature to enjoy smiling. And to appreciate the person (or interface) that made you smile.

\n

As you’ve seen in the examples in this post, there are many ways to be charming. Everything will not work in every interface, but you should always be able to find a style that fits your brand. Everyone benefits from happy users!

\n

Create memorable experiences

\n

Lastly, I’d like to draw a parallel to one of the best articles on user experience I’ve read: User Memory Design: How To Design For Experiences That Last.

\n

In short, the article is based on research done by\u00a0Nobel Prize-winning psychologist Daniel Kahneman and talks about something called the “peak-end rule”. The gist of the rule is:

\n

People\u2019s memories of an experience are based on a rough average of the most intense moment (the peak) and the final moment (the end).

\n

So when people evaluate your interface, their feelings about it will be based mainly on what they felt at the end and what they felt at the most intense moment. So when designing interfaces you should focus on creating\u00a0one powerful peak moment and a great last impression.

\n

You probably see where I’m going with this!

\n

Happy is a powerful feeling. You can use charm and humor to achieve that! It’ll be extra effective if you inject humor when the user is done with a task, like the Mailchimp high-five example from earlier in this article.

\n

Spotify cleverly uses humor in their offboarding by offering the user a “Farewell playlist” when they cancel their subscription:

\n

\"Spotify

\n

Maybe they won’t make a whole lot of users change their mind, but at least the user is more likely to leave with a smile on their face and have a slightly better memory of Spotify, which probably increases the chance they’ll come back some day.

\n

A final joke

\n

I want to live like I learn! Since the article is just about over, here’s a joke:

\n

How many graphic designers does it take to change a light bulb?

\n

Four. One to change the bulb and three to argue about whether they should have used serifed or sans serifed fonts on the packaging.

\n

Ahh, priceless! If I listen closely, I can just about hear the endorphins flowing through your body helping you remember this article!

\n

Hope you enjoyed!

\n

The post Charming interfaces \u2013 make your users smile appeared first on Axess Lab.

\n", "date_published": "2017-09-30T14:26:31+00:00", "date_modified": "2017-10-02T15:40:29+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/web-accessibility-directive/", "url": "https://axesslab.com/web-accessibility-directive/", "title": "Web Accessibility Directive \u2013 What it is and how to comply", "content_html": "

Worried about the new directive on accessibility that you need to follow? Great, you’re in the right place! Here’s everything you need to know about the directive and a seven step guide on how to comply.

\n

\"Eu

\n

About the accessibility directive

\n

In October 2016 the EU parliament approved a directive on digital accessibility that had been worked on since 2012. The directive will become law in all EU-countries.

\n

In this section, we’ll give an overview of the directive. In the next section, we will talk about what steps you need to take to comply.

\n

The directive in a nutshell

\n

\"Squirrel

\n

If you work with web or apps in the public sector, the directive states that you must:

\n
    \n
  1. Make sure your website and apps comply with accessibility standards (more on that later in “What are the actual rules”).
  2. \n
  3. Provide a feedback mechanism where anyone can notify you of failures to comply with the accessibility standards.
  4. \n
  5. Regularly provide a detailed accessibility statement on your compliance, using a template from the EU Commission.
  6. \n
\n

Who is affected

\n

The directive affects EU-countries, and its full name gives a good hint of what is covered: “Directive on the accessibility of the websites and mobile applications of public sector bodies”.

\n

So you’re definitely affected if you \u2013 or your clients \u2013 fulfill the following criteria:

\n\n

Even if you’re not a government organization, you’re still affected by the directive if you:

\n

Provide services that are essential to the public, or services that specifically address the needs of, or are meant for, persons with disabilities.

\n

Exactly what’s considered essential to the public is not clear, but it will likely include companies in the transportation, food and finance industries, among others.

\n

The directive lists some exceptions. The most prominent are:

\n\n

There are a few other exceptions that you can read about in Article 1 Section 4 of the directive if you’re interested.

\n

Will they audit me?

\n

\"Policemen.

\n

Yes. Here are some quotes from the directive:

\n

Member States shall ensure the availability of an adequate and effective enforcement procedure to guarantee compliance with this Directive

\n

Member States shall periodically monitor the compliance of websites and mobile applications of public sector bodies with the accessibility requirements

\n

Member States shall ensure that public sector bodies provide and regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications

\n

So to cite George Orwell: “Big brother is watching you!”

\n

What happens if I don’t comply

\n

The most important problem if you don’t comply is that you’re making it difficult for your users to access your services, especially users with disabilities.

\n

But also, since the directive will be made into a law in each EU country, not conforming to it will literally mean you’re breaking the law. Details about the actual consequences are decided by each country’s authorities and may differ between countries.

\n

Deadlines \u2013 How long do I have to comply?

\n

\"Old

\n\n

This does not mean you can wait until 2019 to address this. Accessibility is a team effort that involves developers, designers, publishers, executives…well basically everyone. If you’re not working actively with accessibility now, it will take time and energy to make accessibility part of your processes and increase the knowledge of your organization.

\n

For most public sector bodies we’ve worked with, it takes about a year of calendar time to put the right strategies in place to become successful with accessibility. So get started in time!

\n

What are the actual rules?

\n

\"Thick

\n

If you want to dive into the actual standard, you should! But be prepared to do some serious reading.

\n

The directive is only 15 pages. But it doesn’t include the actual requirements for complying. Instead it references the EU standard for accessible public procurement which is 134 pages long. In turn, that standard points to WCAG 2.0, which is about 1 000 pages if you include techniques of how to comply with it.

\n

If you are like most people, you don’t have nearly enough time to go through all that. So below we’ve put together a guide to what you need to do to comply with the directive.

\n

Practical seven step guide to compliance

\n

\"Checklist

\n

“Only seven steps!?” you might be thinking, but it gets even better:

\n\n

So here we go! Our guide for building accessible products that comply with the accessibility directive:

\n

1. Educate yourself and colleagues

\n

\"Apple

\n

To succeed with accessibility, different roles need to have the right know-how. Like we said before, accessibility is not a one-man-show, it’s a team effort.

\n

Here are some key roles and the competences they’ll need:

\n\n

Luckily, it doesn’t require weeks of education to get your team on track with accessibility. Most courses offered on accessibility are done in a day or two.

\n

If you don’t have an accessibility professional to teach your team, here are some companies that offer accessibility training:

\n\n

A set up that we like to use is half a day of general training where people get to try out different assistive technologies, understand the users and learn the fundamentals of accessibility. Then we follow that up with half a day of specific accessibility training for different team roles. “Technical accessibility” for developers, “Accessible design” for the User Experience team etc.

\n

2. User test

\n

\"User

\n

User testing is an absolute key task to succeeding with accessibility. If you’re not user testing on a regular basis right now, you should definitely start!

\n

Trust us, we’ve worked with loads of clients who tried to make accessible products just by following different checklists. You will not succeed in building an accessible product unless you let actual users test it. Accessibility and usability are closely related. You can’t have one without the other.

\n

If you’re user testing right now, great! Then all you need to do is start recruiting users with disabilities as test subjects as well. Check out our article on seven tips for user testing with people with disabilities.

\n

3. Rework your style guide

\n

\"Paintbrushes

\n

I can’t even count the number of times an inaccessible style guide has caused problems in web projects. Since the style guide is the foundation that you build all your digital products from, an inaccessible style guide results in problems all across your interfaces.

\n

Usually it’s because it specifies color combinations that have insufficient contrasts. A good tip is to have an accessibility expert work together with your designers to make sure your style guide complies to the accessibility standards.

\n

Put in the effort to rework the style guide once and you’ll see so much fall into place automatically.

\n

4. Feedback mechanism

\n

\"Mailbox.

\n

The directive requires you to have a feedback mechanism that encourages users to comment on accessibility issues. You’ll also need to set up a strategy of how you handle issues that come in through the feedback mechanism.

\n

For example, this can be a special email, like accessibility@yourcompany.com that you add to your contact or support pages of your sites and apps.

\n

Many larger companies also have special social media accounts for accessibility, where they promote work they do on accessibility and encourage feedback and discussions. Get inspired by the following examples on Twitter: @fbaccess, @MSFTEnable and @BarcalaysAccess.

\n

5. Automatic testing

\n

\"Robot

\n

There are plenty of tools out there that help you catch some accessibility issues automatically. However, I need to be really clear on this: automatic tools will not find the majority of accessibility issues in your interface. Accessibility guru Steve Faulkner put it clearly in this tweet:

\n
\n

📢Automated accessibility checking is great, but it needs to be clearly understood that you can only auto-check about 30% of #a11y issues pic.twitter.com/kAXYGqpiOg

\n

\u2014 Steve Faulkner (@stevefaulkner) May 12, 2017

\n

\n

Here’s a great article from Gov.uk on automatic testing tools: What we found when we tested tools on the world\u2019s least-accessible webpage. The overall gist of the article is:

\n

It\u2019s important that teams don\u2019t rely on them too heavily.

\n

Automatic testing tools are a good resource if used together with manual reviews and by a team with accessibility knowledge. But don’t count on them to fix all your problems.

\n

Here are some automatic testing tools that you can compare:

\n\n

6. Manual testing

\n

\"Laptops

\n

You should complement your automatic testing with manual accessibility testing. In other words: let someone who knows about accessibility test your site or app.

\n

Here, you can either work together with accessibility specialists or educate people in your testing or development teams to do the accessibility testing.

\n

You will be required to do manual accessibility testing when you update the accessibility statement required by the directive. How often this needs to be done is not specified in the directive. It just says “regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications”. A good guess is that it will be at least once a year.

\n

A good way to succeed with this is to make accessibility testing part of your agile process. A lot of teams have a “definition-of-done” that specifies the criteria that need to be checked off before they release a new feature. Make both a manual and automatic accessibility test part of the definition-of-done.

\n

7. Procurement and requirements

\n

\"Pen

\n

If you’re not developing your own sites or apps it will be crucial that you have clear accessibility requirements and that you follow up on those requirements.

\n

Just pointing to a standard like WCAG and relying on your client to ship an accessible product is not a good way forward. WCAG is long, abstract and difficult to understand and it’s very likely your contractor didn’t even read it, knowing you probably wouldn’t either. But you are the one getting in trouble if the result is not accessible!

\n

You need to make the requirements concrete and easy to understand. You need to decide how you will test the delivery and state what will happen if the requirements are not fulfilled. You wouldn’t imagine how often organizations fail with this. It’s not rocket science, but you need to be thorough and not take the easy road.

\n

High five!

\n

\"Cat

\n

By following the web directive and creating accessible websites and apps you’re doing a great thing for democracy and people’s independence.

\n

When focusing on the needs of users with disabilities you’ll make your products better for everyone. That’s called design for all and is what accessibility is really about.

\n

On behalf of all users, we thank you for your commitment and wish you the best of luck with your accessibility journey. If you have any questions don’t hesitate to get in touch at hello@axesslab.com.

\n

The post Web Accessibility Directive \u2013 What it is and how to comply appeared first on Axess Lab.

\n", "date_published": "2017-09-27T18:27:22+00:00", "date_modified": "2017-09-28T11:52:48+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/statistics-on-disabilities/", "url": "https://axesslab.com/statistics-on-disabilities/", "title": "Statistics on disabilities \u2013 the one stat you need to know", "content_html": "

We often get asked how many people have a disability. So here is everything we think you need to know about the statistics.

\n

\"Infographic,

\n

Yea, that’s it! You really don’t need to go dig into more details than that.

\n

Accessibility affects everyone in a positive way. And the older you get, the more you’ll depend on accessibility. So start building accessible products right away \u2013 and let us help you if you need a hand!

\n

But if you really, really want to know how many people live permanently with a disability, it’s around 15 % of the world population (who.int).

\n

Text transcript of the infographic

\n

100 % of the world population spend part of their life with a disability.

\n

Here are some examples of why:

\n\n

Accessibility matters to everyone.

\n

Design for all. Always.

\n

The post Statistics on disabilities \u2013 the one stat you need to know appeared first on Axess Lab.

\n", "date_published": "2017-09-19T06:42:05+00:00", "date_modified": "2017-09-19T11:39:57+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/skip-the-wcag/", "url": "https://axesslab.com/skip-the-wcag/", "title": "Skip the WCAG! User test with people with disabilities instead", "content_html": "

If you\u2019re trying to make your website or app accessible, you\u2019ve probably stumbled over the Web Content Accessibility Guidelines (WCAG). But don\u2019t waste your energy trying to understand them. Just don\u2019t.

\n

\"Laptop

\n

Get out and test with actual people

\n

I know it\u2019s a bold statement. But the WCAG will confuse you. And probably scare you away. It\u2019s really, really, really long and difficult to wrap your head around.

\n

How long? Well, I took the WCAG, pasted it into Microsoft Word and zoomed all the way out. Voil\u00e0, here are the 98 pages:

\n

\"Zoomed

\n

On top of that, there are the actual techniques for succeeding \u2013 the blue links on the latter half of the pages above lead to those techniques. Probably another 1 000 pages or so.

\n

So instead of diving into WCAG, if there\u2019s one thing you should do to improve the accessibility of your website or app it\u2019s to let people with disabilities test it.

\n

I\u2019ve done this a lot in my role as an interaction designer at accessibility focused companies. And there is no doubt in my mind: testing with users with disabilities will help you improve accessibility far more than reading any checklist or standard ever could. Period.

\n

“Normal” users are not good enough

\n

Testing with users with disabilities will also help you improve your usability far better than testing with your \u201cregular\u201d test subjects. Why?

\n

Well, for instance, a person with cognitive impairment like autism will react to the same things that another user will. But they go further. They are much better at spotting inconsistencies in design, problems with navigation and unnecessarily difficult content.

\n

Things that other users will find annoying but work their way around without mentioning. In a similar way, a person with low vision will react to small text or low contrast, which will make reading difficult for anyone out in the sun with a smartphone.

\n

If you want to test with people with disabilities, I\u2019ve put together a list of tips to get you going in another article:

\n

Seven tips for user testing with people with disabilities

\n

And if you feel it sounds a bit scary, we can hold your hand and help you with recruiting users and carrying out the tests.

\n

Don’t hang me…

\n

And finally, I turn to the awesome people of the accessibility community: Please don\u2019t hang me for suggesting people to skip the WCAG. The fact is, I love the WCAG! It\u2019s probably one of the most important documents around, all categories. But it should be used by people who\u2019ve matured further in their accessibility career or mindset.

\n

First, you have to witness people in action, otherwise you\u2019ll not understand how to use the WCAG, why it\u2019s around and it\u2019s strengths and limitations. Hope you get what I mean!

\n

The post Skip the WCAG! User test with people with disabilities instead appeared first on Axess Lab.

\n", "date_published": "2017-09-14T10:24:05+00:00", "date_modified": "2017-09-14T10:27:08+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/accessible-datepickers/", "url": "https://axesslab.com/accessible-datepickers/", "title": "Accessible datepickers", "content_html": "

Datepickers often cause problems to assistive technology users and fail several basic criteria in the Web Content Accessibility Guidelines (WCAG). But datepickers can \u2013 and should \u2013 be made accessible. Here is how to do it and a few examples you can steal or get inspired by!

\n

\"Datepicker,

\n

Criteria for accessible datepickers

\n
    \n
  1. Don\u2019t force people to use the datepicker. Make it possible to write directly in the input field as well. And make sure the required format is specified in the label.
  2. \n
  3. Make it possible to navigate with a keyboard (here is where most fail). For example by tabbing to the calendar and using arrow keys to pick the right date.
  4. \n
  5. Don’t hide the calendar button from screen readers. We’ve met a few clients who considered setting aria-hidden=”true”, forcing screen reader users to input directly in the text field. But that’s not a great idea. Some screen reader users use a combination of sight and screen reader, so hiding the calendar button and calendar view for screen readers will harm their user experience. Make the actual datepicker accessible instead.
  6. \n
  7. Make sure that the buttons and icons in the calendar view have proper labels so that they get correctly read by screen readers. For example, the dates of the month should not just be \u201c1\u201d, \u201c2″ etc. They should be read \u201c1 January, Thursday\u201d or something similar. You can use aria-label for this.
  8. \n
\n

Examples of accessible datepickers

\n

Here are a few accessible datepickers that fullfil the criteria above that you can get inspired by:

\n

Accessible Bootstrap Datepicker

\n

Aria Datepicker

\n

Deque Datepicker

\n

WebAxe have some more examples in their article Accessible Date Pickers (webaxe.org).

\n

The post Accessible datepickers appeared first on Axess Lab.

\n", "date_published": "2017-09-06T12:26:29+00:00", "date_modified": "2017-09-09T15:44:05+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/colorblind-accessibility-web-fail-success-cases/", "url": "https://axesslab.com/colorblind-accessibility-web-fail-success-cases/", "title": "Colorblind Accessibility on the Web \u2013 Fail and Success Cases", "content_html": "

It’s Colorblind Awareness Day today! To celebrate, we raise awareness by giving you some practical examples of how design can hurt or help users with color vision deficiencies.

\n

\"Colored

\n

Diagrams and infographics

\n

Diagrams and infographics are common offenders when it comes to creating accessibility barriers for people who can’t tell certain colors apart.

\n

Green and red are the most common colors that are difficult for people to tell apart, which makes the diagram below extra problematic.

\n

\"Table

\n

This is what it would look like with deuteranopia, a color defiency that about 6% of the male population has.

\n

\"\"

\n

Pie charts are usually really inaccessible.

\n
\n

Reasons why I hate pie charts pic.twitter.com/e1ooavL7Zd

\n

\u2014 Color Blind Probs (@WeTheColorBlind) January 28, 2014

\n
\n

\n

If you really want to use a pie chart, put your labels in the chart.

\n

\"Piechart

\n

Or just use a bar chart instead because piecharts kind of suck.

\n

Color pickers

\n

Color pickers without labels will create a barrier for people with color blindness.

\n

\"Color

\n

Instead, label the colors. This will help all users, since it can be hard to see the difference between certain colors like black, tortoise and brown. The great example below is from warbyparker.com.

\n

\"Labels

\n

Apple also does a good job with this. Instead of showing a color palette they show the actual product in the different colors, with a label below.

\n

\"Shopping

\n

Toggles

\n

Here is what one person on Twitter answered when asked what causes accessibility problems for people with disabilities:

\n
\n

Colourblind. Text on background is usually fine, but things like colour-coded toggles, heatmaps, etc can be hard.

\n

\u2014 Dan 🇪🇺🇨🇦 (@phrawzty) June 4, 2017

\n

\n

This is what iPhone’s toggles look like if you remove colors. Which one is on and which one is off?

\n

\"A

\n

A simple solution is to just use check boxes instead:

\n

\"Checkboxes

\n

Error messages

\n

A red frame around error messages is not good enough, like illustrated by this image from the great article Designing eCommerce for colourblind users (uxplanet.org):

\n

\"Error

\n

You need to make the error stand out more clearly by adding an error message:

\n

\"Error

\n

Links

\n

Don’t just use color to differentiate links from other text. If you remove the color it’s really difficult to understand that the heading “Modules” is clickable in the example below.

\n

\"Links

\n

You can use color, but in combination with something structural, like an underline, a link icon or a button design.

\n

Here are a few examples of links that work well even if you have a color vision deficiency.

\n

\"Links

\n

Contrasts

\n

Make sure that you have sufficient contrasts between your colors. Avoid writing text on top of images, like in the example below from the article Improving The Color Accessibility For Color-Blind Users (smashingmagazine.com):

\n

\"Text

\n

Make the background darker to improve the contrasts:

\n

\"Text

\n

Measure your contrasts and make sure they are at least 4.5:1. Here’s a list of our favorite free color contrast checkers.

\n

Below is an image of a big contrast fail in real life:

\n

\"Sign

\n

The overall accessibility guideline

\n

The guideline for creating accessible content for people with color vision deficiencies is pretty straight forward:

\n

Color is not used as the only visual means of conveying information (Level A)
\n– Web Content Accessibility Guidelines 2.0

\n

So it’s fine to use colors to convey information, as long as it’s also conveyed in some other way.

\n

A great way to check it is by viewing your design in greyscale before each release. You can use the free tool\u00a0Funkify to do it right in your browser.

\n

Keep updated on color blindness

\n

Here are tips of two awesome Twitter accounts to follow that raise awareness on color blindness:

\n

@colourblindorg
\n@WeTheColorBlind

\n

And while you’re following great accounts on Twitter, follow me as well: @hampelusken!

\n

Let’s end with this Tweet from @colourblindorg showing that color problems limit people outside of the web as well.

\n
\n

1/2 Why no section for ppl unable to watch matches due to ‘colour blind’ kit clashes #1in12men #1in200women @EHCR?https://t.co/bHnx8cqj1K pic.twitter.com/2jssIGPicA

\n

\u2014 ColourBlindAwareness (@colourblindorg) August 11, 2017

\n

\n

The post Colorblind Accessibility on the Web \u2013 Fail and Success Cases appeared first on Axess Lab.

\n", "date_published": "2017-09-06T05:43:00+00:00", "date_modified": "2017-09-06T10:21:01+00:00", "author": { "name": "Hampus Sethfors" } }, { "id": "https://axesslab.com/fonts-dont-matter/", "url": "https://axesslab.com/fonts-dont-matter/", "title": "Fonts don’t matter", "content_html": "

If you’re an art director or font fanatic, you might want to sit down for this. Take a few deep breaths. Go to your happy place. Because I’m going to explain why fonts are overrated and what actually matters for readability.

\n

\"Letters

\n

The hard truth

\n

What’s important when picking out a font?

\n

It’s one of the most common questions I get when I consult in accessibility.

\n

People expect me to start lecturing on the importance of fonts for people with dyslexia or other reading impairments.

\n

How different typefaces and kerning really can make a difference for the readers.

\n

How the choice of serifs or sans serifs in headings is as close to a life-or-death changing decision a web designer can get.

\n

So I always get perplexed reactions when I reply:

\n

Actually, font’s do not matter very much…

\n

I know it’s a really bold thing to say. Telling web designers that fonts don’t matter is like stealing a kid’s favorite toy.

\n

\"Sad

\n

But before you compose an angry tweet about it or respond with a “Fonts matter a lot” article on Medium, please hear me out.

\n

Fonts are overrated

\n

I’m asked to talk about fonts so often that I consulted members of the Dyslexia Association here in Sweden. They are experts on readability and get font questions so often that they even had a prepackaged answer referencing different studies made on the subject.

\n

Here’s the gist of what they had to say:

\n

The energy put on fonts is hugely overrated. There are other things that are of much greater importance for our members.
\n– Representative from the Swedish Dyslexic Association

\n

The folks at Dyslexia Action agree with this:

\n

Research shows that\u00a0fonts matter relatively little.
\n– dyslexiaaction.org

\n

What really matters for readability

\n

So first I want to go through what really matters to people with reading impairments. At the end of the article you’ll find some pointers on fonts as well. You’re only allowed to read that once you’ve understood the other things that matter more. So promise me you won’t skip to that right away.

\n

Structure the text – headings, sub headings and paragraphs

\n

Here are two of the answers from our article Accessibility According to Actual People with Disabilities:

\n
\n

Dyslexic – not really seen as a disability, but large walls of text is painful.
\nAlso never ending sentences and over complicated language.

\n

\u2014 Mustafa Kurtuldu (@Mustafa_x) June 3, 2017

\n

\n
\n

When ppl type large blocks of text w/ no spaces added

\n

\u2014 Dead Ass (@MeBeShe4815) June 3, 2017

\n

\n

So giving your text a reader friendly structure is important.

\n

Here are a few things you can do to structure the text in a nice way:

\n\n

\"Illustration

\n

Complement text

\n

Letting users choose how to obtain the content is a key to accessibility.

\n

Work on complementing text content with:

\n\n

I tie a tie about once every five years. I’m happy for the combination of video, text and illustrations on tie-a-tie.net (see example below). Usually I look at the illustrations, but if I can’t figure them out I switch to the video. I have a friend who is completely blind. He prefers the text version.

\n

\"Screenshot

\n

The point is that we can choose, and that’s awesome!

\n

Don’t use italics

\n

I could cite a few studies done on the readability of italics, but instead I’ll just write this in italics to prove my point. It takes more effort to read for everyone. Especially words you don’t come across very often, like absquatulate. On top of that, imagine that you have a reading impairment where letters tend to blend together. Then italics will make things so much worse. So just don’t use italics.

\n

Keep it clean

\n

Let the user focus on the content without distractions.

\n

Avoid:

\n\n

Ladies, gentlemen and everyone in between, I present to you the pride of my home country Sweden, the world’s most cluttered site: Arngren.net.

\n

\"Startpage

\n

Gaah! Do not follow their example.

\n

Line length \u2013 keep them short!

\n

A common problem for people with reading difficulty is that they jump to the wrong line of text at line breaks if the lines are too long. In other words, when you can’t find the way from the end of one line to the beginning of the next line.

\n

One way to reduce this problem is by keeping paragraphs short.

\n

Another important guideline is to keep line length short. 50\u201375 characters \u2013 including spacing \u2013 per line is a good line length guideline for big screens. Shorter of course on mobile screens.

\n

Line height \u2013 make it large enough

\n

Usually the problem with line height on websites is that it’s too tight. This contributes to the problem for the user finding the next line from the previous one. It can also make the page feel like a “wall of text”, a common comment when user testing with people with dyslexia.

\n

A good guideline is to use a line height that’s 150 % of the font size (Smashing magazine). It’s what we use on this site.

\n

Font size \u2013 make it large enough

\n

Anyone who has used their phone to surf to a site that is not adapted to small screens knows that font size matters for readability.

\n

As with line height, the problem is usually that it’s too small. It probably has to do with the fact that most people who design websites are young and have a better than average vision.

\n

Show your interface to someone who is over 65 years old and see if they pinch or hold the device really close to their eyes when reading.

\n

Usually we see font sizes between 15\u201318 pixels on the web. Here is one good reason to crank that up a few pixels:

\n

A larger typeface has been proven to enhance readability for all types of users, regardless of one\u2019s age or quality of eyesight.
\n\u2013 Your body text is too small (marvelapp.com)

\n

Here’s a rule of thumb I made up that should work for most designers:

\n

Pick a font size that you think is nice. Then make it at least 2 pixels bigger.

\n

What matters with fonts and accessibility

\n

Yes, I lied in the title of the article. A little bit. Because even though fonts are overrated and get far too much energy and attention in projects, I’m not arguing that they don’t matter at all. Just that other things matter far more.

\n

For example, if you’d use Comic Sans on your site many readers would probably react.

\n

\"angry

\n

If you’ve done your best with all the other factors that I’ve mentioned above, then it’s time to think about the font.

\n

So here are some pointers when choosing a font for good readability.

\n

Pick a common font

\n

When studies compare reading speed and user preference of different fonts, common fonts usually win.

\n

People tend to prefer reading letters they’re used to reading.
\n\u2013 Representative from the Swedish Dyslexic Association

\n

…duh! Quite obvious when it’s put in that way, right?

\n

When a font looks odd, it’s hard to focus on the actual content.

\n

The best font choices are ones where the reader does not notice the font, but the message
\n\u2013 WebdesignerDepot.com

\n

Which font are common on the web? Here’s a great article on the most popular fonts on the web (theultralinx.com).

\n

A note on “dyslexia friendly” fonts

\n

There are a few fonts out there that market themselves as “dyslexia friendly” and they’ve gotten a lot of spread lately.

\n

Below is Open Dyslectic, probably the most well known font designed for readers with dyslexia. As you can see, the foot of each letter is bold, which is meant to reduce risk of flipping the letters around when reading.

\n

\"Font

\n

However, people with dyslexia tend to prefer common fonts to dyslexia-friendly fonts when comparing them.

\n

Special fonts often result in the reader mentally thinking about the font, when reading actually is about getting beyond the font and reading the content.
\n\u2013 Representative from the Swedish Dyslexic Association

\n

There is no evidence that dyslexia fonts help people with dyslexia to read faster and more accurately.
\n\u2013 Understood.org

\n

So don’t overestimate their dyslexia friendliness. Use common fonts instead.

\n

Let people choose

\n

Depending on what type of interface you’re building, it might be a good idea to make it possible for your users to switch to a font they prefer. Most e-book readers \u2013 like Amazon Kindle below \u2013 have a feature to pick font, line spacing, margins and more.

\"Interface

\n

Web browsers also let users set global font and color schemes. Try it out in the settings of your browser and make sure it works on your site.

\n

\"Font

\n

Safari’s Reader Mode also let’s the user pick fonts, colors and sizes that they prefer:

\n

\"Reader

\n

Far from everyone who need the font styling features will find them, so you still need to format the default text in a way that works well for readers.

\n

Even though it can be good to let users pick their fonts in some interfaces, it’s doesn’t work for all of them. For example, if you place a font changing feature in the header of a website, it’s usually not something that users will find or bother to use. They want to set it globally so it affects everything they read \u2013 like in the Reader Mode on Safari \u2013 not have to do it separately on each individual site.

\n

Serif or sans-serif

\n

\"Two

\n

The question of serif \u2013 squiggly decorative ends of strokes on letters \u2013 or sans-serif font is always a well debated issue. Some readers think it helps the flow of the text, others will say it causes letters to blend into each other.

\n

So I will recommend you to fall back to the previous guidelines:

\n\n

Final words

\n

I’ve sat countless of hours in web design meetings where fonts choice was debated back and forth. I just want to cry out “Please put this energy on making great content, user testing, information architecture or something else that matters more!”

\n

Sadly, I’m way too polite to say that out loud. Instead I hide behind my keyboard and write this article about it.

\n

So please help me out. Do talk about fonts in your projects. But keep it to a reasonable amount. Pick one, then move on to something more important.

\n

The post Fonts don’t matter appeared first on Axess Lab.

\n", "date_published": "2017-09-01T13:45:27+00:00", "date_modified": "2017-09-07T08:04:07+00:00", "author": { "name": "Hampus Sethfors" } } ] }