{ "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/scotland/", "url": "https://axesslab.com/scotland/", "title": "Slides from Accessibility Scotland", "content_html": "

Hey Accessibility Scotland! I like you guys even though you invented golf…

\n

\"Scotland

\n

Here are the slides from my talk:
\nHave you tried to dab some coconut oil on your spine (PowerPoint on Dropbox)

\n

Enjoy!

\n

And while you’re here, you might as well check out our other articles on accessibility.

\n

The post Slides from Accessibility Scotland appeared first on Axess Lab.

\n", "content_text": "Hey Accessibility Scotland! I like you guys even though you invented golf…\n\nHere are the slides from my talk:\nHave you tried to dab some coconut oil on your spine (PowerPoint on Dropbox)\nEnjoy!\nAnd while you’re here, you might as well check out our other articles on accessibility.\nThe post Slides from Accessibility Scotland appeared first on Axess Lab.", "date_published": "2018-11-08T12:03:16+01:00", "date_modified": "2018-11-08T19:27:51+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/11/flag.png" }, { "id": "https://axesslab.com/accessible-comics/", "url": "https://axesslab.com/accessible-comics/", "title": "Accessible Comics", "content_html": "

A lot of the accessibility initiatives today are focused on web sites and apps. But there’s of course more to the digital world than that. In this article we’ll look at a case where a team has done great work to make their digital comic accessible to people with visual impairments.

\n

\"Comic

\n

Let’s start with a small experiment!

\n

Imagine a blind person.

\n

What image pops up in your head?

\n

Is it a young person? Is the person at their work? Doing sports? At the cinema? Buying an Apple Watch? Reading a comic? Probably not.

\n

There are many preconceived ideas out there about what people with disabilities do, or rather don’t do. If you don’t have a visual impairment yourself or some blind friends, you probably don’t think of blind people in the above situations. Most people tend to think of an old person with a cane, not doing much. Which of course is a problem that for instance affects how people are treated, job recruitment and which products are made accessible.

\n

So we need to get more people to see people with disabilities as a diverse group with all sorts of jobs, interests and hobbies. And we need to get more people to understand that their users have disabilities, which is what the article “Our users have no disabilities” is all about.

\n

Making a comic accessible

\n

With this in mind, I was pleasantly surprised when the team behind a comic contacted us, asking for advice on the style of alt-texts for their comic: 100 Demon Dialogues.

\n

Sidenote: this might seem like a sponsored article, but it’s not. We’re just thrilled to see the great job this team has done and want to share it with you!

\n

Most people would never think about making a comic accessible for people with visual impairments. After all, comics are very visual.

\n

\"Three

\n

But the author Lucy Bellwood \u2013 in the image above \u2013 is more inclusive than most people. She wanted to make her comic accessible to comic lovers with visual impairments as well, and brought a team together to get it done. So they asked us to review a couple of alt-texts they had written. It turned out that they’d already grasped the concept very well so our advice was basically: “Great job, keep doing what you’re doing. And can we write about this when it’s out?”

\n

And now the comic is out. We tested it with a screen reader \u2013 an assistive technology that speaks alt-texts to the user \u2013 and the experience is awesome.

\n

So below are two short, short videos.

\n
    \n
  1. An inaccessible experience of a regular comic where the screen reader just says “Background” when it tries to read the content.
  2. \n
  3. The accessible 100 Demon Diaries comic that reads the well crafted alt-texts, which both explain what’s happening visually in the comic and what’s written in text.
  4. \n
\n

\n

\n

It’s so great seeing people making their products accessible, especially when barely anyone else in their field are doing it. Hopefully it motivates more people to do the same thing and opens more people’s minds as to the diverse interests of people with disabilities!

\n

If you’re as happy with this initiative as we are please spread the word about this and give the author Lucy Bellwood (@LuBellWoo) and her team with Kate Brednow, Andy McMillan (@andymcmillan) and Jason Alderman (@justsomeguy) a shoutout on Twitter.

\n

I also strongly recommend the Tumblr A11y Wins \u2013 a site that’s dedicated to showcasing positive accessibility examples.

\n

If you want to check out the comic, you can find it in the following places:

\n\n

The post Accessible Comics appeared first on Axess Lab.

\n", "content_text": "A lot of the accessibility initiatives today are focused on web sites and apps. But there’s of course more to the digital world than that. In this article we’ll look at a case where a team has done great work to make their digital comic accessible to people with visual impairments.\n\nLet’s start with a small experiment!\nImagine a blind person.\nWhat image pops up in your head?\nIs it a young person? Is the person at their work? Doing sports? At the cinema? Buying an Apple Watch? Reading a comic? Probably not.\nThere are many preconceived ideas out there about what people with disabilities do, or rather don’t do. If you don’t have a visual impairment yourself or some blind friends, you probably don’t think of blind people in the above situations. Most people tend to think of an old person with a cane, not doing much. Which of course is a problem that for instance affects how people are treated, job recruitment and which products are made accessible.\nSo we need to get more people to see people with disabilities as a diverse group with all sorts of jobs, interests and hobbies. And we need to get more people to understand that their users have disabilities, which is what the article “Our users have no disabilities” is all about.\nMaking a comic accessible\nWith this in mind, I was pleasantly surprised when the team behind a comic contacted us, asking for advice on the style of alt-texts for their comic: 100 Demon Dialogues.\nSidenote: this might seem like a sponsored article, but it’s not. We’re just thrilled to see the great job this team has done and want to share it with you!\nMost people would never think about making a comic accessible for people with visual impairments. After all, comics are very visual.\n\nBut the author Lucy Bellwood \u2013 in the image above \u2013 is more inclusive than most people. She wanted to make her comic accessible to comic lovers with visual impairments as well, and brought a team together to get it done. So they asked us to review a couple of alt-texts they had written. It turned out that they’d already grasped the concept very well so our advice was basically: “Great job, keep doing what you’re doing. And can we write about this when it’s out?”\nAnd now the comic is out. We tested it with a screen reader \u2013 an assistive technology that speaks alt-texts to the user \u2013 and the experience is awesome.\nSo below are two short, short videos.\n\nAn inaccessible experience of a regular comic where the screen reader just says “Background” when it tries to read the content.\nThe accessible 100 Demon Diaries comic that reads the well crafted alt-texts, which both explain what’s happening visually in the comic and what’s written in text.\n\n\n\nIt’s so great seeing people making their products accessible, especially when barely anyone else in their field are doing it. Hopefully it motivates more people to do the same thing and opens more people’s minds as to the diverse interests of people with disabilities!\nIf you’re as happy with this initiative as we are please spread the word about this and give the author Lucy Bellwood (@LuBellWoo) and her team with Kate Brednow, Andy McMillan (@andymcmillan) and Jason Alderman (@justsomeguy) a shoutout on Twitter.\nI also strongly recommend the Tumblr A11y Wins \u2013 a site that’s dedicated to showcasing positive accessibility examples.\nIf you want to check out the comic, you can find it in the following places:\n\nSearch for “100 demon dialogues” in iBooks.\nAmazon\nGumroad\n\nThe post Accessible Comics appeared first on Axess Lab.", "date_published": "2018-08-07T10:47:48+01:00", "date_modified": "2018-08-11T09:27:01+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/08/featured-3.png" }, { "id": "https://axesslab.com/lgbtq-inclusive-web-design/", "url": "https://axesslab.com/lgbtq-inclusive-web-design/", "title": "LGBTQ-inclusive web design", "content_html": "

It’s pride week here in Stockholm, Sweden! So we thought we’d celebrate by sharing a few tips on how to create a LGBTQ-inclusive digital environment.

\n

\"Computer

\n

Here at Axess Lab we specialise in accessibility and inclusive design \u2013 which is about making sure as many people as possible feel great about using your products and services. \u00a0Accessibility and inclusive design is often focused on people with disabilities, but let’s look at two concrete things you can do to make your digital products awesome from a pride perspective!

\n

1. The gender question

\n

Many forms include a question about the user’s gender.

\n

\"Two

\n

Do you really need to know this information? If the answer isn’t a clear “yes”, then the best idea is probably to just remove it. A lot of services ask for users’ gender without really needing it. Simply not asking for gender is great because of a few reasons:

\n
    \n
  1. You reduce the length of your form by one field. And it’s a fact that reducing the number of form fields increases conversion rates (searchenginepeople.com)
  2. \n
  3. Your users don’t start questioning your intents. A lot of companies ask for gender information to be able to send you specific marketing. Many users know this and get suspicious.
  4. \n
  5. You don’t risk excluding users who has another gender identity than the ones you specify.
  6. \n
\n

If, however, you really need gender information you can ask for the information in an inclusive way.

\n

The examples below are from the article Designing forms for gender diversity and inclusion by Sabrina Fonseca and the talk All inclusive design – excluding no gender by Sara Ler\u00e9n (@HeedTheNeed).

\n

The first step that many have already adapted is to add an alternative for “Other”. This is better \u2013 or should I say “less bad” \u2013 than the binary “Male/female”. But people who identify as male or female get their own categories while everyone else are mashed together to “other”. We can do better!

\n

\"Radiobuttons

\n

Sometimes the simplest solutions are the best: a custom input field where the user can type whatever they want. Also note how you can explain why you need the gender information below the field.

\n

\"Input

\n

You could include a custom input field after a male and female radio buttons, like this:

\n

\"Male,

\n

Including a “Rather not say”, like in the example below, is great as well. It gives people the chance to skip the field, and many who identify as something other than male or female are extra cautious about sharing that information online. Seeing the huge problems with for example transphobia around the world, everyone will not want their gender identity registered in some online database. Combine the “Rather not say” alternative with a custom input field, and you’ve come a long way with little effort!

\n

\"Input

\n

If you want to go all-in, check out Facebook. They’ve done a lot of work with their gender questions. There’s a huge list of gender identity “tags” to choose from, and if you don’t find the correct one you can add to the list yourself. Also, they ask for your preferred pronoun, making it possible to prefer a gender neutral pronoun with examples on how it will be used: “Wish them a happy birthday”.

\n

\"Facebook

\n

2. Choose inclusive images and illustrations

\n

Our second tip to becoming more LGBTQ-friendly is to work with your images and illustrations.

\n

A lot of people can rarely or never identify with the people that are represented in images or illustrations on websites, social media and the like. What you choose to display there says a lot about who your target audience is, so make sure it’s as diverse as possible to feel relevant to all your potential users.

\n

Break as many norms as possible in your imagery. Show women playing sport, men taking care of kids, a person in a wheelchair coding, a family with two dads and so on. And make sure not everyone in your images are white.

\n

Below are some great examples of inclusive images you can get inspired by.

\n

The Swedish army fight for LGBTQ-rights:

\n

\"Person

\n

Facebook shows icons of two men instead of a man and a woman when two men get married:

\n

\"Facebook

\n

I recommend everyone to check out this Swedish guide: Images that change the world. Even if you don’t know Swedish, just flip through the guide and look at the great images, you’ll get the point!

\n

Here’s one of the images featured in it, pointing out that older LGBTQ-couples are extremely rare to see in images.

\n

\"Two

\n

Here’s a great banner image on St\u00e5ng\u00e5staden a Swedish site for renting apartments:

\n

\"Top

\n

The Swedish youth clinic site has some awesome, inclusive illustrations on their site. The great thing about the one below is that it’s on a page about friendship. It’s not on a page about dating with disabilities. So they picked an inclusive image without making a point of it. This is a great way to help widen the norms we live by.

\n

\"Black

\n

Sometimes it can be difficult to find inclusive images, especially on regular stock photography sites. But luckily Jenny Hellenberg (@jenhell) shared some good tips with me, so here are some great places to look for images with diversity:

\n

\"Screenshot

\n\n

Hope this inspired you to keep improving your inclusive design!
\nHappy pride everyone!

\n

The post LGBTQ-inclusive web design appeared first on Axess Lab.

\n", "content_text": "It’s pride week here in Stockholm, Sweden! So we thought we’d celebrate by sharing a few tips on how to create a LGBTQ-inclusive digital environment.\n\nHere at Axess Lab we specialise in accessibility and inclusive design \u2013 which is about making sure as many people as possible feel great about using your products and services. \u00a0Accessibility and inclusive design is often focused on people with disabilities, but let’s look at two concrete things you can do to make your digital products awesome from a pride perspective!\n1. The gender question\nMany forms include a question about the user’s gender.\n\nDo you really need to know this information? If the answer isn’t a clear “yes”, then the best idea is probably to just remove it. A lot of services ask for users’ gender without really needing it. Simply not asking for gender is great because of a few reasons:\n\nYou reduce the length of your form by one field. And it’s a fact that reducing the number of form fields increases conversion rates (searchenginepeople.com)\nYour users don’t start questioning your intents. A lot of companies ask for gender information to be able to send you specific marketing. Many users know this and get suspicious.\nYou don’t risk excluding users who has another gender identity than the ones you specify.\n\nIf, however, you really need gender information you can ask for the information in an inclusive way.\nThe examples below are from the article Designing forms for gender diversity and inclusion by Sabrina Fonseca and the talk All inclusive design – excluding no gender by Sara Ler\u00e9n (@HeedTheNeed).\nThe first step that many have already adapted is to add an alternative for “Other”. This is better \u2013 or should I say “less bad” \u2013 than the binary “Male/female”. But people who identify as male or female get their own categories while everyone else are mashed together to “other”. We can do better!\n\nSometimes the simplest solutions are the best: a custom input field where the user can type whatever they want. Also note how you can explain why you need the gender information below the field.\n\nYou could include a custom input field after a male and female radio buttons, like this:\n\nIncluding a “Rather not say”, like in the example below, is great as well. It gives people the chance to skip the field, and many who identify as something other than male or female are extra cautious about sharing that information online. Seeing the huge problems with for example transphobia around the world, everyone will not want their gender identity registered in some online database. Combine the “Rather not say” alternative with a custom input field, and you’ve come a long way with little effort!\n\nIf you want to go all-in, check out Facebook. They’ve done a lot of work with their gender questions. There’s a huge list of gender identity “tags” to choose from, and if you don’t find the correct one you can add to the list yourself. Also, they ask for your preferred pronoun, making it possible to prefer a gender neutral pronoun with examples on how it will be used: “Wish them a happy birthday”.\n\n2. Choose inclusive images and illustrations\nOur second tip to becoming more LGBTQ-friendly is to work with your images and illustrations.\nA lot of people can rarely or never identify with the people that are represented in images or illustrations on websites, social media and the like. What you choose to display there says a lot about who your target audience is, so make sure it’s as diverse as possible to feel relevant to all your potential users.\nBreak as many norms as possible in your imagery. Show women playing sport, men taking care of kids, a person in a wheelchair coding, a family with two dads and so on. And make sure not everyone in your images are white.\nBelow are some great examples of inclusive images you can get inspired by.\nThe Swedish army fight for LGBTQ-rights:\n\nFacebook shows icons of two men instead of a man and a woman when two men get married:\n\nI recommend everyone to check out this Swedish guide: Images that change the world. Even if you don’t know Swedish, just flip through the guide and look at the great images, you’ll get the point!\nHere’s one of the images featured in it, pointing out that older LGBTQ-couples are extremely rare to see in images.\n\nHere’s a great banner image on St\u00e5ng\u00e5staden a Swedish site for renting apartments:\n\nThe Swedish youth clinic site has some awesome, inclusive illustrations on their site. The great thing about the one below is that it’s on a page about friendship. It’s not on a page about dating with disabilities. So they picked an inclusive image without making a point of it. This is a great way to help widen the norms we live by.\n\nSometimes it can be difficult to find inclusive images, especially on regular stock photography sites. But luckily Jenny Hellenberg (@jenhell) shared some good tips with me, so here are some great places to look for images with diversity:\n\n\nLGBT section at Twenty20\u00a0(the screenshot above is from this site)\nUnsplash (free)\nBlendimages\nPhotoability\nGetty images lean in collection\n\nHope this inspired you to keep improving your inclusive design!\nHappy pride everyone!\nThe post LGBTQ-inclusive web design appeared first on Axess Lab.", "date_published": "2018-08-02T16:29:27+01:00", "date_modified": "2018-11-02T10:08:11+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/08/featured-1.png" }, { "id": "https://axesslab.com/skip-links/", "url": "https://axesslab.com/skip-links/", "title": "Your skip links are broken", "content_html": "

Many websites have an accessibility feature called skip links that help some users navigate the site. However, there’s a problem with basically all skip links on mobile devices, which hurts your site’s accessibility instead of improving it.

\n

\"Button

\n

What are skip links?

\n

Skip links are a common accessibility feature on websites. They are simply shortcuts to important parts of the webpage that makes it easier and quicker for some users \u2013 especially users with disabilities \u2013 to find their way around.

\n

Skip links are usually hidden visually by default and appear when users navigate to them using the tab key on their keyboard. “Who would ever use a keyboard to navigate?” you may ask yourself. Well, lots of people actually! For instance many users with motor or sight impairments will rely on keyboard navigation. But more on the use cases under the next heading.

\n

If you want to try out a skip link using your laptop, go to Starbuck’s website and press the tab key after you have entered the site.

\n

Here’s an attempt at illustrating what happens.\u00a0

\"Starbucks

\n

So when you “tab into” the site the skip link appears, and you can activate it with the Enter key to skip to where it points. On Starbuck’s site you can (in theory) skip to either the main navigation, content or footer.

\n

Skip links work well on desktop. Here’s a short video where I’m using them on a few sites with the VoiceOver screen reader on Mac. It might be a bit difficult to follow along if you’re unused to hearing a screen reader in action, and to make things worse mine switches between Swedish and English. But the important thing to notice is how the focus indicator jumps into the content area after I press the skip links:

\n

\n

Skip links are great when they work, and this type of functionality is recommended in the Web Content Accessibility Guidelines (WCAG):

\n

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

\n

\u2013 WCAG 2.1

\n\n

Skip links are mainly used by:

\n\n

Instead of having to spend time tabbing through the logotype, links in the header, menu, etcetera, on each page you visit, skip links provide a handy shortcut to jump straight to what you’re after.

\n

They’re also quite popular among users. In the latest Web AIM screen reader user survey \u2013 which almost 1800 people responded to \u2013\u00a0over 30% said they always or often use skip links when they are present.

\n

We’ve seen in user tests that skip links are even more used by novice screen reader users. Tech savvy users tend to use shortcuts on their keyboard or special gestures to skip between different parts of the page. But less “techy” users are not always aware of those features, and will instead often use the skip link to find their way to the main content.

\n

The problem

\n

We became aware of a major issue with skip links after seeing it in two user tests a few months apart, where two different screen reader users struggled with the same type of problem on two different websites.

\n

One of our clients was kind enough to let us share a video clip from their user test in this article. So thanks, Council of the European Union, for that ❤️. The user in the test has also given us her consent to spread this video.

\n

So take a look at this clip (sorry for the blurry start), then we’ll tear apart exactly what’s happening.

\n

\n

So in the clip we see a screen reader user trying to use the skip link with her iPhone. This is what happens:

\n
    \n
  1. She activates the skip link.
  2. \n
  3. The page scrolls down visually \u2013 which she and other blind user will not be helped by.
  4. \n
  5. She swipes right to go to the next object \u2013 you can think of it like pressing the tab key on a desktop.
  6. \n
  7. The screen reader puts focus on the cookie message, not the main content.
  8. \n
  9. She naturally gets quite confused and annoyed.
  10. \n
\n

We started investigating the problem and found the same issue on every single skip link we tested. You can try it yourself if you know how to use the screen reader on your smartphone at these sites:

\n\n

Or just check out this video where we try to use skip links with VoiceOver on an iPhone on the sites above. You’ll see the sites scrolling, but as soon as we swipe the screen to go to the next item, we’re back at the top of the page.

\n

\n

Skip links are almost always constructed in the same way. They are simply anchor links pointing to a part of the page like <main>. Something like this:

\n
\n<a href="#skip-here">Skip to main content</a>\n\n//Menu and other stuff users might want to skip\n\n<main id="skip-here">\n...\n
\n

For some reason, these simple anchor links don’t work as intended on iOS. We tried in Safari, Firefox and Chrome \u2013 all have the same issue.

\n

To be clear, this problem exist on mobile when the user navigates by swiping to go from one object to the next. There is another way of navigating (explore by touch \u2013 moving your finger over objects on the screen), and then it works fine on iOS.\u00a0

\n

Affects Android as well, but in a different way

\n

Regular skip links don’t work with VoiceOver on iOS as shown above. Sadly they don’t work with Android’s screen reader TalkBack either, but this time it’s not the anchor link that’s causing the problems.

\n

In Talkback, skip links don’t even show up when the screen reader focuses on them. Here’s a video where you’ll\u00a0hear the skip link being announced, but it’s not showing on the screen like in iOS. We try to activate the link when it’s announced, but nothing happens.

\n

\n

This is caused by a bug in Android that stops the focus event from being triggered. It’s probably easiest to understand if you look at this video comparing what happens when tabbing on desktop, using VoiceOver on iOS and using TalkBack on Android. You’ll see that when tabbing on desktop or using an iOS screen reader, the focused links turn orange. On Android, you never see the orange focus style.

\n

\n

For some reason, Android doesn’t trigger the CSS focus event with TalkBack. This is the reason skip links never show up visually on Android, since they are programmed to show up when they receive focus. This is a bug reported to Google, so hopefully they’ll fix it soon.

\n

But shouldn’t it still be possible to use the link, even though it’s visually hidden? Sadly, that’s not possible. If you click on a hidden link with TalkBack, the link will not be activated. So, we guess that Google will need to fix this focus issue before skip links will work at all on Android.

\n

Interesting enough, some Android phones have a version of TalkBack called VoiceAssistant. With VoiceAssistant, skip links work exactly as intended!

\n

What can you do?

\n

Solving this bug is mostly up to browser and screen reader vendors. So we hope you’re listening Google, Apple, Mozilla and the rest.

\n

But there are some things you as a site owner can do while we wait for a more robust solution.

\n

We created and played around with this codepen where you can test skip links that reference different types of elements like headings, <main>, <span>, <div>, and more. We found cases where including the attribute tabindex="-1" on the element you reference would solve the issue, but unfortunately only for iOS users. Here’s how:

\n
\n<a href="#skip-here">Skip to main content</a>\n\n//Menu and other stuff users might want to skip\n...\n<main id="skip-here" tabindex="-1">\n...\n
\n

So simply adding tabindex="-1" to the element you’re skip link points to is the best solution we can offer at the moment. It won’t make your skip links work for all your screen reader users, but at least you’ll have catered the needs of the majority of them.

\n

See update 3 below for problems with this solution and other, better ways to solve this

\n

Update 1 \u2013 a better solution!

\n

A lot of clever people read our articles, and it turns out that there’s an even better solution. Paul J. Adam (@pauljadam) uses javascript to move focus to the first heading. Like this with jQuery:

\n
\n$('#skip-link').click(function(e) {\ne.preventDefault();\n$(':header:first').attr('tabindex', '-1').focus();\n});\n
\n

It works splendidly! Check it out on Paul’s website.

\n

Update 2 – Vanilla javascript solution

\n

Ben Buchanan made a regular “vanilla” javascript solution from Paul Adam’s solution above, since many people don’t use jQuery. And he was also kind enough to share it with us and the world, so here it is:

\n

Codepen – Working skip links using vanilla JS

\n

Update 3 – A comment from gov.uk

\n

Anika Henke e-mailed us some great input:

\n

I’m a developer working in the accessibility team at GDS (the people behind gov.uk).

\n

I was made aware of your article about skip links and that it mentions gov.uk.

\n

We investigated the very same issue on gov.uk last year and I created a bug report for the iOS issue as it’s clearly a browser or screen reader bug.

\n

Your suggested solution introduces worse barriers, though. See our Pull Request about removing tabindex from main to understand why. To quote:

\n

“When clicking anywhere in the page focus will return back to the top. Consider a user interacting with an input field who clicks away from it to remove the focus style. Should they then hit tab they will be taken to the top of the page.”

\n

The JavaScript solutions are a bit better because they focus on a smaller element. But it is too specific. It is dependent on certain elements or IDs being present.

\n

Since ages I’ve been using a better fix in my personal projects which fixes all in-pages links, not just skip links, and removes the tabindex the moment the focus moves away.

\n

Thanks for that great input Anika!

\n

The post Your skip links are broken appeared first on Axess Lab.

\n", "content_text": "Many websites have an accessibility feature called skip links that help some users navigate the site. However, there’s a problem with basically all skip links on mobile devices, which hurts your site’s accessibility instead of improving it.\n\nWhat are skip links?\nSkip links are a common accessibility feature on websites. They are simply shortcuts to important parts of the webpage that makes it easier and quicker for some users \u2013 especially users with disabilities \u2013 to find their way around.\nSkip links are usually hidden visually by default and appear when users navigate to them using the tab key on their keyboard. “Who would ever use a keyboard to navigate?” you may ask yourself. Well, lots of people actually! For instance many users with motor or sight impairments will rely on keyboard navigation. But more on the use cases under the next heading.\nIf you want to try out a skip link using your laptop, go to Starbuck’s website and press the tab key after you have entered the site.\nHere’s an attempt at illustrating what happens.\u00a0\nSo when you “tab into” the site the skip link appears, and you can activate it with the Enter key to skip to where it points. On Starbuck’s site you can (in theory) skip to either the main navigation, content or footer.\nSkip links work well on desktop. Here’s a short video where I’m using them on a few sites with the VoiceOver screen reader on Mac. It might be a bit difficult to follow along if you’re unused to hearing a screen reader in action, and to make things worse mine switches between Swedish and English. But the important thing to notice is how the focus indicator jumps into the content area after I press the skip links:\n\nSkip links are great when they work, and this type of functionality is recommended in the Web Content Accessibility Guidelines (WCAG):\n2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.\n\u2013 WCAG 2.1\nWho are skip links for?\nSkip links are mainly used by:\n\nUsers with motor impairments who navigate with a keyboard instead of a mouse.\nUsers with motor impairments who navigate with switches.\nUsers with severe visual impairments who use screen readers\u00a0on desktop or mobile devices.\nUsers with low vision who use\u00a0screen magnification software\u00a0in combination with keyboard navigation.\n\nInstead of having to spend time tabbing through the logotype, links in the header, menu, etcetera, on each page you visit, skip links provide a handy shortcut to jump straight to what you’re after.\nThey’re also quite popular among users. In the latest Web AIM screen reader user survey \u2013 which almost 1800 people responded to \u2013\u00a0over 30% said they always or often use skip links when they are present.\nWe’ve seen in user tests that skip links are even more used by novice screen reader users. Tech savvy users tend to use shortcuts on their keyboard or special gestures to skip between different parts of the page. But less “techy” users are not always aware of those features, and will instead often use the skip link to find their way to the main content.\nThe problem\nWe became aware of a major issue with skip links after seeing it in two user tests a few months apart, where two different screen reader users struggled with the same type of problem on two different websites.\nOne of our clients was kind enough to let us share a video clip from their user test in this article. So thanks, Council of the European Union, for that ❤️. The user in the test has also given us her consent to spread this video.\nSo take a look at this clip (sorry for the blurry start), then we’ll tear apart exactly what’s happening.\n\nSo in the clip we see a screen reader user trying to use the skip link with her iPhone. This is what happens:\n\nShe activates the skip link.\nThe page scrolls down visually \u2013 which she and other blind user will not be helped by.\nShe swipes right to go to the next object \u2013 you can think of it like pressing the tab key on a desktop.\nThe screen reader puts focus on the cookie message, not the main content.\nShe naturally gets quite confused and annoyed.\n\nWe started investigating the problem and found the same issue on every single skip link we tested. You can try it yourself if you know how to use the screen reader on your smartphone at these sites:\n\nwww.starbucks.com\nwww.slack.com\nwww.gov.uk\n\nOr just check out this video where we try to use skip links with VoiceOver on an iPhone on the sites above. You’ll see the sites scrolling, but as soon as we swipe the screen to go to the next item, we’re back at the top of the page.\n\nSkip links are almost always constructed in the same way. They are simply anchor links pointing to a part of the page like <main>. Something like this:\n\n<a href="#skip-here">Skip to main content</a>\n\n//Menu and other stuff users might want to skip\n\n<main id="skip-here">\n...\n\nFor some reason, these simple anchor links don’t work as intended on iOS. We tried in Safari, Firefox and Chrome \u2013 all have the same issue.\nTo be clear, this problem exist on mobile when the user navigates by swiping to go from one object to the next. There is another way of navigating (explore by touch \u2013 moving your finger over objects on the screen), and then it works fine on iOS.\u00a0\nAffects Android as well, but in a different way\nRegular skip links don’t work with VoiceOver on iOS as shown above. Sadly they don’t work with Android’s screen reader TalkBack either, but this time it’s not the anchor link that’s causing the problems.\nIn Talkback, skip links don’t even show up when the screen reader focuses on them. Here’s a video where you’ll\u00a0hear the skip link being announced, but it’s not showing on the screen like in iOS. We try to activate the link when it’s announced, but nothing happens.\n\nThis is caused by a bug in Android that stops the focus event from being triggered. It’s probably easiest to understand if you look at this video comparing what happens when tabbing on desktop, using VoiceOver on iOS and using TalkBack on Android. You’ll see that when tabbing on desktop or using an iOS screen reader, the focused links turn orange. On Android, you never see the orange focus style.\n\nFor some reason, Android doesn’t trigger the CSS focus event with TalkBack. This is the reason skip links never show up visually on Android, since they are programmed to show up when they receive focus. This is a bug reported to Google, so hopefully they’ll fix it soon.\nBut shouldn’t it still be possible to use the link, even though it’s visually hidden? Sadly, that’s not possible. If you click on a hidden link with TalkBack, the link will not be activated. So, we guess that Google will need to fix this focus issue before skip links will work at all on Android.\nInteresting enough, some Android phones have a version of TalkBack called VoiceAssistant. With VoiceAssistant, skip links work exactly as intended!\nWhat can you do?\nSolving this bug is mostly up to browser and screen reader vendors. So we hope you’re listening Google, Apple, Mozilla and the rest.\nBut there are some things you as a site owner can do while we wait for a more robust solution.\nWe created and played around with this codepen where you can test skip links that reference different types of elements like headings, <main>, <span>, <div>, and more. We found cases where including the attribute tabindex="-1" on the element you reference would solve the issue, but unfortunately only for iOS users. Here’s how:\n\n<a href="#skip-here">Skip to main content</a>\n\n//Menu and other stuff users might want to skip\n...\n<main id="skip-here" tabindex="-1">\n...\n\nSo simply adding tabindex="-1" to the element you’re skip link points to is the best solution we can offer at the moment. It won’t make your skip links work for all your screen reader users, but at least you’ll have catered the needs of the majority of them. \nSee update 3 below for problems with this solution and other, better ways to solve this\nUpdate 1 \u2013 a better solution!\nA lot of clever people read our articles, and it turns out that there’s an even better solution. Paul J. Adam (@pauljadam) uses javascript to move focus to the first heading. Like this with jQuery: \n\n$('#skip-link').click(function(e) {\ne.preventDefault();\n$(':header:first').attr('tabindex', '-1').focus();\n});\n\nIt works splendidly! Check it out on Paul’s website.\nUpdate 2 – Vanilla javascript solution\nBen Buchanan made a regular “vanilla” javascript solution from Paul Adam’s solution above, since many people don’t use jQuery. And he was also kind enough to share it with us and the world, so here it is:\nCodepen – Working skip links using vanilla JS\nUpdate 3 – A comment from gov.uk\nAnika Henke e-mailed us some great input: \nI’m a developer working in the accessibility team at GDS (the people behind gov.uk).\nI was made aware of your article about skip links and that it mentions gov.uk.\nWe investigated the very same issue on gov.uk last year and I created a bug report for the iOS issue as it’s clearly a browser or screen reader bug.\nYour suggested solution introduces worse barriers, though. See our Pull Request about removing tabindex from main to understand why. To quote:\n“When clicking anywhere in the page focus will return back to the top. Consider a user interacting with an input field who clicks away from it to remove the focus style. Should they then hit tab they will be taken to the top of the page.”\nThe JavaScript solutions are a bit better because they focus on a smaller element. But it is too specific. It is dependent on certain elements or IDs being present.\nSince ages I’ve been using a better fix in my personal projects which fixes all in-pages links, not just skip links, and removes the tabindex the moment the focus moves away.\nThanks for that great input Anika! \nThe post Your skip links are broken appeared first on Axess Lab.", "date_published": "2018-06-21T10:16:59+01:00", "date_modified": "2018-09-17T16:15:12+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/06/skipsquare.png" }, { "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", "content_text": "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\nWe\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.\nHave 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!\nFor 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. \nIf 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. \nOops! I clicked it again\nMany 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! \nA 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\nHere 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\nIf 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!\nHere’s a quote from the video that explains the essence of it:\nThey 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\nThe simple solution\nIt would help enormously if there was just a little bit of space between each touch target in the list. Like this:\n\nNow 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! \nThis is how it looks on our site, scrolling through our\u00a0articles. Not too shabby, right?\n\nHey browsers! You can help out too\nAnother 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\nThe 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. \nBut wait! Why isn\u2019t this in the accessibility guidelines?\nWe 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\nTouch screen scrolling has only been around since the smartphone revolution, like ten years. Seems like long enough, but the WCAG is a standard and standards move at glacier speeds. The 2.0 version WCAG was released in 2008 and it’s not until the summer of 2018 \u2013 ten years later \u2013 that\u00a0WCAG 2.1\u00a0arrives.\nThere’s a lack of knowledge about accessibility issues that affect users with motor impairment. \nThe WCAG is primarily focused on vision impairments and assistive technologies. Motor impairments are sadly not covered as well, which they\u2019re trying to change but not succeeding with. For instance, for a long time it was looking like they would add a minimum touch target size criteria to the new 2.1 version of WCAG, at level AA. But sadly, last minute this criteria was bumped up to level AAA, basically meaning nobody will care about it since all legislations and requirements are concerned with level A and level AA. \n\nWhatever 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!\nAlso, 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).\nLet’s make the web more hand tremor friendly\nThanks 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!\nIf you liked this article, here are some others you might enjoy:\n\nAccessibility according to actual people with disabilities\nPractical examples of accessibility improvements\nAssistive technologies \u2013 The switch\n\nThe post Hand tremors and the giant-button-problem appeared first on Axess Lab.", "date_published": "2018-04-09T09:37:36+01:00", "date_modified": "2018-04-09T09:50:48+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/04/featured.png" }, { "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", "content_text": "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\nThe problem\nFirst 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. \nWhat I should hear when touching a link with my finger is:\n\nThe name of the link.\nWhat type of element it is: “link”.\n\nFor instance: “Contact information, link”. \nHowever, sometimes I just get to hear what type of element it is, not it’s name. Just “Link”. Not very helpful.\nThe 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\nNotice 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.\nWhat’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\nIn 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. \nBut VoiceOver interprets it as two different objects if I touch the right span, rendering me confused.\nOK, so Apple should fix this?\nYes, 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.\nThe solution: role=”text”\nWe 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. \nHere I’ve got an h1-element that looks like this in the code:\n<h1>Digital accessibility, <br>\nfor everyone.</h1>\n\nAs 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\nSo 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\nAnd voil\u00e1, here is the result:\n\nBeware! 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. \nApple, 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. \nUpdate \u2013 questions and answers\nThis post went a bit viral! Which is great, but I’ve gotten a few questions that I want to clarify. \nCan’t we just use aria-hidden on the icon?\nYes, 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. \nSo 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\nHere, VoiceOver would announce them as separate links: “Buy link”, “t-shirts link”, “now link”. \nNow 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. \nHowever, using the role=”text” technique will work great in this scenario as well.\nIs this just a problem with explore by touch?\nTo 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. \nOne person asked if this problem only occurs if you explore by touch. \nHowever, sadly it happens both on explore by touch and when swiping. \nWhy don’t you keep writing to Apple?\nApple have actually answered me. They think this is a feature. It makes it possible to recognize that different words are styled in different ways. \nI 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. \nOne idea would be to make the styling differences clear in some other way, like changing the pitch of the voice. \nThe post Text Splitting Causes Screen Reader Problems appeared first on Axess Lab.", "date_published": "2018-03-04T16:41:18+01:00", "date_modified": "2018-03-09T18:27:34+01:00", "author": { "name": "DanielGoransson", "url": "https://axesslab.com/author/danielgoransson/", "avatar": "https://secure.gravatar.com/avatar/d276c4825491378b09d00085946cc412?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/03/featured.png" }, { "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", "content_text": "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\nSo what is a switch?\nAt 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.\nThe classic example of a switch looks like a big round button:\n\nThis type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it.\nOn 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.\nVideo 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 \nWorld 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\nOn 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.\nMost 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.\nAnother 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.\nUsually these types of switches come with a lip-controlled joystick that moves the mouse cursor on the screen.\nHere’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\nHere’s a similar product, Integramouse.\n\nNot 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.\nHow to design switch-friendly interfaces\nHere are some things for developers and designers to think about when designing digital interfaces for switch users.\n\nMake your interface keyboard accessible.\nThat is, make sure you can control it only using the tab, space and arrow keys of your keyboard. If that doesn’t work, then switch users most likely will run into trouble.\nPlace key information, buttons and links “above the fold” \u2013 visible without scrolling.\nScrolling usually requires a lot more time and effort for switch users. With iOS Switch Control, a user needs to activate the switch seven times to scroll: 2 clicks to see the interaction menu, 3 clicks to navigate and activate the scroll and 2 clicks to remove the menu.\nDon’t require hover, click-and-drag or other advanced gestures.\nAlthough most switch interfaces have functionality for these gestures, they take a lot of effort to carry out and many less tech-savvy users will not know about them.\nUse a large text size as default.\nMany switch control users physically can’t lean close to a screen to read tiny, italics text.\nAvoid time limits.\nIt will take most switch control users longer to complete a form or navigate your interface. So avoid using time limits. But if you do, make sure to give the user a way of increasing the time and give them a warning long before time’s up.\n\nThere 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!\nHope you learned something new! Thanks for reading and leveling up your accessibility know-how!\nThe post Assistive Technologies \u2013 The Switch appeared first on Axess Lab.", "date_published": "2018-02-19T15:26:53+01:00", "date_modified": "2018-02-19T20:30:37+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/02/Featured.png" }, { "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", "content_text": "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\nWhat’s a title text?\nHere 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.\nDemo link with title\nThis is how it looks:\n\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…\nThe problem with title texts\n1. Title texts don’t work on touch screens\nTitle 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.\n2.\u00a0Title texts cause problems for screen magnifiers\nFor 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.\nAnother 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. \nYou 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.\nAs 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.\n3. Title texts don’t work with keyboard navigation\nApart 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.\n4. Title texts require users to guess\nThere 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.\n5. Title texts require users to wait\nNot 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.\n6. Screen readers read title texts inconsistently\nMany 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.\nThe point is, title texts are handled differently and you can’t rely on how it’s conveyed to the user.\nDon’t trust me?\nDavid Ball of @silktide wrote this nicely researched piece on the same subject a few years ago:\nI thought title text improved accessibility. I was wrong.\nHe 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\nWeb 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\nAlso, here’s another nice article on title texts: Don’t rely on the title attribute for accessibility.\nWhat should I use instead of title texts?\nWell, 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.\nDon’t confuse title texts with alt-texts. Alt-texts are very important and don’t suck at all:\nAlt-texts: the Ultimate Guide\nWhat about iframes?\nSome 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.\nBut 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.\nOther things that suck\nThis was our third article on the topic of things that suck. You should check out our other two master pieces:\nDisabled Buttons Suck\nCaptchas Suck\nHope you enjoyed!\nThe post Title Texts Suck appeared first on Axess Lab.", "date_published": "2018-02-08T16:15:51+01:00", "date_modified": "2018-02-13T17:37:51+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/02/featured.png" }, { "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", "content_text": "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\nWe, 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.\nEven 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.\nThe deal\nAs 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\nIt’s done outside of working hours\nThe project or task is related to accessibility, inclusive design or something similar\n\nThe 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.\nThat’s it. We don’t make it more complicated than that.\nWhat’s in it for us?\nWhy would a startup like us do this. Well, we see many benefits:\n\nIt makes our employees even more skilled at accessibility.\nIt’s a good way to give something back to the open source community\nIt increases our chances of recruiting great people to our company\nIt aligns with our company’s vision of creating a more inclusive digital world\nIt makes our employees happy\n\nWant to know more?\nHopefully this will inspire some other companies to set up something similar.\nIf you want to know more, get in touch with us by mailing hello@axesslab.com or tweeting @axesslab.\nYou’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!\nThe post Paying Employees to Work on Open Source Projects appeared first on Axess Lab.", "date_published": "2018-01-18T10:41:11+01:00", "date_modified": "2018-01-18T11:46:39+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2018/01/featured.jpg" }, { "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", "content_text": "It’s been a great 2017 at Axess Lab! We celebrate by listing our most popular articles all year.\n\nThe podium\nHere are the top three. Congratulations!\nAccessibility 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.\nHow 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.\nAlt-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.\nHappy losers\nHere are some articles that fought hard but just missed the podium. Ouch!\nDisabled 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.\nFonts 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.\nTop 7 Free Color Contrast Checkers\nSeven great free tools that help you measure color contrasts and create beautiful, accessible color schemes\nThe post Our Top Articles 2017 appeared first on Axess Lab.", "date_published": "2017-12-29T13:01:13+01:00", "date_modified": "2017-12-29T13:01:13+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/12/featured-1.jpg" }, { "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", "content_text": "“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\nOffer alternatives\nAccessibility is a lot about offering people alternatives.\nHere’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.\nWe solved it by offering an alternative. Users can now either use the slider or input the numbers directly in the input fields.\nThis 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.\nHere are some other examples of offering alternatives to users:\nInstead of forcing people to call customer service, offer an alternative to write in a chat or email.\nInstead of forcing people to understand a diagram, offer an alternative to see the data in a table:\nInstead of forcing people to read an article, offer an alternative to watch a video:\nNote 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!\nColors\nThere are two main things to keep in mind when it comes to colors and accessibility: color contrasts and not relying solely on color.\nColor contrasts\nGood 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.\nHere’s an example of light gray text on Squarespace that doesn’t fulfill the contrast guidelines in the Web Content Accessibility Guidelines (WCAG):\n\nA normal contrast failure is for link colors. Mediatemple have links that are far from acceptable:\n\nTo 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.\nYou 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?\nAnyway, it’s easy to measure contrasts yourself. Here are some free contrast checkers we recommend!\nDon’t rely solely on color\nSome people with color vision deficiencies can’t tell different colors apart.\nHere’s an example that would create problems:Simply labeling your colors is a way to make color pickers accessible:\nA common fail to this criteria is links that are only blue:\nViewing this in grayscale makes it clear why this is important:\nSome ways to make your links pop out is underlining them, giving them link icons or making them look like buttons:\nIf you want to know more on this subject, check out our article on color blind accessibility.\nKeyboard accessibility\nSome 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?\nFocus indication\nMake sure that it’s clear which element has focus when tabbing around in your interface.\nThe default focus indicator varies between browsers, but it’s often not very easy to spot.\n\nSome 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\nOn gov.uk focus is indicated with an orange background that really stands out from the surrounding:\nSo design a clear focus indicator and implement it using the :focus selector in your css.\nSkip-links\nSkip-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.\nThey 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.\nHere’s a skip-link in action at www.starbucks.com.\nTry 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).\nScreen reader accessibility\nMaking 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.\nAnother 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.You should check out our Ultimate Guide to Alt-texts!\nAccessibility 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.\nWrapping it up\nThere 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.\nAccessible 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!\nFinally, I’d want to recommend the world’s best tumblr:\na11ywins.tumblr.com\nIt’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!\nThe post Practical Examples of Accessibility Improvements appeared first on Axess Lab.", "date_published": "2017-12-28T17:33:08+01:00", "date_modified": "2017-12-29T12:32:55+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/12/featured.jpg" }, { "id": "https://axesslab.com/users-no-disabilities/", "url": "https://axesslab.com/users-no-disabilities/", "title": "\u201cOur Users Have no Disabilities\u201d", "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", "content_text": "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\nThings we hear all the time\nWhen 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:\nI work on an intranet. We don’t have disabled employees.\nOur customers are athletes, not handicapped people.\nI’m building a site for this upcoming movie. Obviously, blind people are not part of my target audience.\nThe 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.\nSo, let’s bust some myths and straighten this thing out once and for all!\nAll disabilities are not visible\nMost 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\nAutism\nAdhd\nHard of hearing\nDyslexia\nColor vision deficiency\nChronic pain\nMental illness\nMany more\n\nEven 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.\nHere I am, roller skating!\n\nSo guess what! You’ll probably pass a lot of people today that have disabilities, but you won’t even notice!\nAnd me roller skating leads us nicely onto the next topic…\nPeople with disabilities have interests too\nThere 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.\nSome of my favorite interests are:\n\nVideo games \u00a0\u2013 not special games for special people. Right now I’m playing Tekken 7, accessible to me through great sound design and contrasts.\nSports \u2013 I both like to watch sports and play it myself. I play a type of soccer that involves eye shades and sounds. Here’s a link to the best goals in the 2016 Paralympics.\nMovies \u2013 Contrary to popular belief, many blind people enjoy movies. I use a combination of the little sight I have and audio descriptions that describe what’s happening, like who’s beating up whom in a fight scene.\n\nI 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.\nThe point is we are different and have many interests!\nThis means that we buy soccer shoes, book movies tickets and hang out on video game review sites. And skateboards!\n\nSo let’s agree on that you can’t assume that their target audience has no disabilities. We are everywhere!\nYoung people have disabilities too\nMany 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.\nThink 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.\nWe 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!\nEmployed people have disabilities too\nOne 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.\nThis, of course, is false.\nPeople 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!\nAnd even if you don’t have a colleague right now who is, say, blind, that doesn’t mean you can assume you never will.\nLet’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.\nIn that scenario, apart from the terrible discrimination, you also lose a great recruitment.\nSo don’t just make your external website accessible. The inside counts as well!\nYou can’t know your user’s environment\nImpairments 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.\nIn 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.\nTech enables\nDigital services like apps and web are often more important to people with disabilities than the so called average Joe out there.\nLet’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\nBut Stephen Murray is also very reliant on the accessibility of the services that he uses. More so than most other people.\nSay 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.\nStephen 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.\nOne last tip\nNow 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\nHere 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!\nThanks for reading and keep on spreading accessibility awareness!\nThe post “Our Users Have no Disabilities” appeared first on Axess Lab.", "date_published": "2017-12-17T12:45:08+01:00", "date_modified": "2017-12-18T21:56:32+01:00", "author": { "name": "DanielGoransson", "url": "https://axesslab.com/author/danielgoransson/", "avatar": "https://secure.gravatar.com/avatar/d276c4825491378b09d00085946cc412?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/12/featured.png" }, { "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", "content_text": "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\nThis is a guest post by Bryn Gelbart from Fueled, who builds apps with accessibility in mind.\nWhy care about app accessibility?\nOne 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.\nAn 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.\n1. Design for colorblindness\nApproximately 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.\nA 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.\nIt 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.\nYou 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.\nThe screenshot from Candy Crush Saga below uses distinct shapes and varied shades to cater to colorblind users:\n\n2. Provide captions and alternative text\nCaptions 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.\nAdditionally, 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.\nTo add this alternative description to images and icons in apps, refer to these guides provided by Google and Apple:\nAndroid Accessibility \niOS Accessibility \nIn short, for Android use android:contentDescription and for iOS use the label attribute.\nAnother 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\n3. Readable and distinguishable interface\nMaking 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.\nIt 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.\nAlso, keep formatting consistent. Users with cognitive limitations may become confused if components are formatted differently on different pages.\n4. Be aware of seizure inducing elements\nAccording 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.\nAvoid 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.\n5. Multiple language settings\nWhile 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.\nAn 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.\nThanks Fueled\nIt’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!\nThe post 5 Ways to Make Your App More Accessible appeared first on Axess Lab.", "date_published": "2017-11-21T09:10:44+01:00", "date_modified": "2017-11-21T09:11:21+01:00", "author": { "name": "Guest", "url": "https://axesslab.com/author/guest/", "avatar": "https://secure.gravatar.com/avatar/ed8776b2593c28dccb74bfa0478cf431?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/11/featured.jpg" }, { "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", "content_text": "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.\nExplain what happened in text, please!\nOk, so I use a screen reader that speaks information about the elements on the screen as I hold my finger over them.\nThe 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.\nI couldn’t swipe across the screen to find elements to interact with, which I usually can.\nAfter 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.\nSo 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!\nThe post iPhone X \u2013 Welcome Screen Inaccessible to Blind Users appeared first on Axess Lab.", "date_published": "2017-11-17T14:25:05+01:00", "date_modified": "2017-11-17T14:30:15+01:00", "author": { "name": "DanielGoransson", "url": "https://axesslab.com/author/danielgoransson/", "avatar": "https://secure.gravatar.com/avatar/d276c4825491378b09d00085946cc412?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/11/How-to-Setup-iPhone-X-1.png" }, { "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", "content_text": "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\nIntroducing the evil\nNobody 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.\nI’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.\nCaptchas 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.\nThey come in some different shapes and forms. Here’s one that everyone would struggle with:\n\nHere is a captcha to sign up to a movie website, which \u2013 at least \u2013 is a bit whimsical!\n\nCaptchas are seriously inaccessible\nImagine 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.\nProve you’re not a robot. Click on the animals in the image below.\n\nYou can’t see any animals, but luckily you find a give-me-a-new-challenge-button. You click it:\nProve you’re not a robot. Solve this simple math problem:\n\nThese may be silly examples, but it’s a pretty accurate experience of how many people with disabilities experience captchas.\nFor users who are blind or have visual impairments, these types of image-captchas are usually impossible to solve:\n\nFor users with learning impairments, a math problem like 21+42 can feel like a complex integral:\n\nFor users with dyslexia or other reading impairments, blurry images of squiggly text can be impossible to solve.\n\nUsers share their feelings\nHere are some users \u2013 with and without disabilities \u2013 expressing their not so loving feelings towards captchas on Twitter.\n\nI 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\nhttps://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\nAs 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\nAs 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\nDear @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\nStupid captcha is blocking me from completing AWS registration!!! arghhh i hate captchas\n— Jos\u00e9 Rodrigues (@jrocharodrigues) October 23, 2017\n\nNo, Google’s new ReCAPTCHA is not good enough\nYou might have come across the “I’m not a robot” captcha:\n\nIt’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.\nHere 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\nAlso, here’s a robot beating a captcha\u00a0😂\n\nNo, the audio alternative is not good enough\nMany 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.\nAnother 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.\nA 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:\nAn 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.\nCaptchas hurt conversions\nSo 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.\nEveryone struggle with captchas, not just people with disabilities. Many have conducted A/B tests and shown how they hurt conversion rates.\nWebnographer 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)\nThey 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)\nSo \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.\nWhat to do instead\nThrow it out\nThe first thing you should consider is to just not have a captcha.\nSifting 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)\nHaving an accessible site with high conversion rate might be worth the spam.\nAlso, 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.\nDon\u2019t make users take responsibility for our problems.\n\u2013 Beyond Captcha (sitepoint.com)\nReplace the captcha with an accessible alternatives\nThere are ways to verify your users without using a captcha. Here’s one example that allows users to skip the captcha:\n\nCheck out these articles on Captcha alternatives:\n9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)\nNot 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”.\nThink Your Site Needs A CAPTCHA? (usertesting.com)\u00a0\nSame as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.\nA final poem to captchas\nSo 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.\nBut 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.\nAnyway, here goes!\nDear captcha.\nThey 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>\nSo duck you, captcha.\nDuck\u00a0your squiggly faded tilted letters.\nDuck you for making users squint and curse.\nDuck you for excluding users with disabilities.\nYou 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\nTo 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.\nDevelopers, web designers, user experience professionals.\nYou’re smart, creative, empathetic people.\nGoogle “captcha alternatives”. Start questioning them.\nYou can do better than a captcha.\nThe post Captchas Suck appeared first on Axess Lab.", "date_published": "2017-11-02T17:01:07+01:00", "date_modified": "2018-02-12T15:51:39+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/11/captchas-suck-featured.png" }, { "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", "content_text": "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\nTrend #1: Bright and light\nFor 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.\nThin, small, grey font\u00a0💩\nSlim, 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\nRunning this interface through the disability simulator Funkify, this is what the interface above looks like with blurry vision:\n\nNot very pleasant, right?\nNobody likes to strain their eyes when reading, but this trend is especially hurtful to some user groups:\n\nUsers with small devices\nPeople who are outside in bright sunlight\nElderly users\nPeople with low vision\n\nWhen 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\nNearly 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\nI know what you’re thinking: It’s Apple’s fault!\nYes, 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.\nThe 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.\nThat’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:\nSo Apple is moving away from the thin, grey trend. You should too.\nBright color schemes\u00a0💩\nMany users with disabilities struggle on the web because of contrast issues in trendy interfaces.\n\nLack 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\nThe color contrasts between the text and backgrounds above are terrible and far below the accepted contrast level in the Web Content Accessibility Guidelines (WCAG).\nLike the tweet above said, another common contrast problem is when text is placed right on top of images, which is trendy now.\n\nSo start measuring contrasts and make your content easy to read for all your users.\nGhost buttons\u00a0💩\nGhost buttons\u00a0are transparent,\u00a0thin buttons that have become popular lately. Like the name suggests, it’s quite a frightening design trend!\nThe background overpowers the important content, making the buttons harder to spot and read:\n\nMake buttons stand out. It improves usability, conversions and accessibility. I think it’s time to stop scaring users away with ghost buttons.\nTrend #2: Motion\nMotion 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\nADHD: 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\nAssuming 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\nrelated, 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\nLet’s look closer at two motion trends that are annoying users: parallax scroll and image carousels.\nParallax scroll\u00a0💩💩\nParallax 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.\nDon’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.\nYou’re not alone in thinking that’s frustrating!\nHere’s an example where animations start cluttering the interface as the user scrolls:\nhttps://axesslab.com/wp-content/uploads/2017/10/parallax2.mp4\nIt 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.\nTry the madness yourself at parall.ax.\nImage carousels\u00a0💩\nImage 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\nWhy are carousels bad? I’ll let my favorite site on the web tell you the answer: shouldiuseacarousel.com.\nTrend #3: Inaccessible social media posts\nIn feeds all across social media platforms, we’re seeing posts that exclude users with low vision or reading impairments. Let me take two examples.\nImages of text\u00a0💩\n“Hahaha check out this epic meme:”\n\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.\nSome 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.\nLet’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\nMuch better right? And more along the lines of the experience a sighted user has:\n\nThe 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.\nIf you’re interested in learning more about accessible images in social media, check out this article on accessible social media posting.\nVideos with text only\u00a0💩\nAn 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.\nHowever, lately this nice trend has shifted a bit too far. Now many skip the soundtrack altogether and only write text in videos.\nHere’s an example, in Swedish but you get the point:\nhttps://axesslab.com/wp-content/uploads/2017/10/lxI7vf.mp4\nThis excludes users who have a severe sight or reading impairment who depend on a voice narrating the video.\nSo 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!\nTrend #4: Icons only\u00a0💩\nIcons 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\nHowever, 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.\nApart 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”.\nA 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:\nTo 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\nNot a very nice user experience, right? So the icons-without-text-labels-trend is causing problems for all sorts of users.\nWhy, oh why, does this happen?\nHere’s my theory as to why so many new trends exclude users.\nGo to Google Images and search for “web designers”. You’ll get a lot of results like this one:\n\nYoung 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.\nAlmost anything looks good on such an expensive screen!\u00a0However, the users’ reality is often a lot different.\nMost 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.\nWhat should we do about it?\nGlad you asked! Here are my three best tips on reducing the excluding-trends-problem.\n1. User test with a wider audience\nI 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\nOld people\nPeople who are not fluent in your language\nPeople with disabilities\n\nUser 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!\n2. Train your team\nThe 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!\n3. Test with Funkify\nWe’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!\nHere’s a demo of the plugin in action:\nhttps://axesslab.com/wp-content/uploads/2017/10/Anv\u00e4nder-Funkify.mp4\nThat’s all, folks!\nLet’s work together to embrace inclusive trends that make the digital world a better place for all users!\nThe post Trends That Exclude appeared first on Axess Lab.", "date_published": "2017-10-18T14:04:41+01:00", "date_modified": "2017-10-27T09:33:03+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/10/game-figure-598036_1920-1-e1508058053798.jpg", "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", "content_text": "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\nMy experience of images on the web\nI 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.\nI, 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.\nMany times the alt-text is not helpful, often even a waste of my time because it doesn’t convey any meaning.\nLet me illustrate this on The Verge’s startpage. This is what it looks like for sighted people:\n\nBelow is what I see. I’ve replaced the images with what my screen reader reads:\n\nNot very useful, huh?\nHere are some common alt-text-fails I come across:\n\n“cropped_img32_900px.png” or “1521591232.jpg” \u2013 the file names, probably because the image has no alt-attribute.\n“<Article title>” \u2013 on every image in the article, probably for improving search ranking (SEO).\n“Photographer: Emma Lee” \u2013 probably because the editor doesn’t know what an alt-text is for.\n\nAlt-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!\nWhat is an alt-text\nAn 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\npeople with little or no vision\npeople who have turned off images to save data\nsearch engines\n\nThe 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.\nAlt-texts are super important! So important that the Web Content Accessibility Guidelines (WCAG) have alt-texts as their very first guideline:\nAll 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\nHow do I add an alt-text?\nIn html, an alt-text is an attribute in an image element:\nHTML\n<img src="dog.png" alt="Dog playing in meadow." />\nMost content management systems (CMS), like WordPress, let you create the alt-text when you upload an image:\n\nThe field is usually named “Alt-text”, “Alternative text” or “Alt”, but in some interfaces it’s called “Image description” or something similar.\nLet’s create the perfect alt-text!\nHere are the steps to crafting fabulous alt-texts!\nDescribe the image\nIt 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.”\nThings that do not belong in an alt-text are:\n\nThe name of the photographer. This is very common, but makes absolutely no sense.\nKeywords for search engine optimization. Don’t cram alt-text with irrelevant words you’re hoping to rank high on Google with. That’s not what alt-texts are for and it will confuse your users.\n\nContent of the alt-text depends on context\nHow you describe the image depends on its context. Let me give you an example:\n\nIf 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.”\nIf 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.”\nSo write an alt-text that is as meaningful as possible for the user in the context they’re in.\nKeep it concise\nReading 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?”\nGlad you asked!\nWell 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.\nOne 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.\nBut the general rule of thumb is to keep it concise and avoid a verbose experience.\nDon’t say it’s an image\nDon’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.\nOne 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.”\nEnd with a period.\nEnd 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.\nDon’t use the title-attribute\nMany 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.\nWhen not to use an alt-text\nIn 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.\nRepeated images in feeds\nPretend 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!\nOther examples of feeds are:\n\nA list of links to articles. Like the one on our page Articles.\nChat or messaging feeds\nFeeds of comments\n\nSo for an ideal user experience, leave the alt-text blank for images that are used repeatedly in feeds.\nIcons with text labels\nYou should always have text labels next to icons. Assuming you do, the icon should not have an alt-text. Let me explain why!\nLet’s take a social media button as an example:\n\nIf you would write an alt text to the Facebook icon, a screen reader would say something along the line: “Facebook Facebook.” Very redundant!\nOK, 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>\nAnother common mistake with icons is on menu buttons:\n\nIf 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.\nIf 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?\nImages in links\nUsually an image within a link is accompanied by a link text. Like in the example below:\n\nIn 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.\nIf 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.\nDecorative images\nPreferably, 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.\nI’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\nSpecial cases\nLogos in the banner\nLogos in the banner almost always link to the websites start page. The opinions vary a bit on the topic of alt-texts for logos.\nSome 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.”\nIn 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.\nSvg\nScalable 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.\nThere are a two main ways of adding an svg to an html-page.\n\nInside 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\nUsing 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>.\n\nActually, 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.\nCan’t a machine do this for me?\nAlthough 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.\nFacebook 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.\nSo I’m sorry, you still have to write alt-texts yourself!\nThanks for making the web better!\nI’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!\nThe post Alt-texts: The Ultimate Guide appeared first on Axess Lab.", "date_published": "2017-10-15T18:44:25+01:00", "date_modified": "2017-10-16T13:02:54+01:00", "author": { "name": "DanielGoransson", "url": "https://axesslab.com/author/danielgoransson/", "avatar": "https://secure.gravatar.com/avatar/d276c4825491378b09d00085946cc412?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/10/cat-square-1.jpg" }, { "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", "content_text": "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\nHey…aren’t you accessibility experts?\nYes, at Axess Lab we specialize in accessibility.\nBut what does this post have to do with accessibility? Are you really allowed to use humor around people with disabilities?\nWell, I’ve carried out some rigorous research and it turns out people with disabilities actually enjoy having fun!\nAlso, since technology is usually full of frustrating accessibility issues, I’d argue that people with disabilities benefit more from charismatic interfaces than most users.\nThe polite registration form\nIn 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.\nA 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.\nI finally gave up, cursed and went to their registration screen to set up a new account. I was in a terrible mood.\nI typed my first name in the registration form. A message popped up to the right of the field:\n\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!”\nProbably the first complement I had got all week! It. Felt. Great!\nI was probably humming Lego The Movie’s themesong “Everything is awesome” as I finished the last two fields.\n 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!\nHow to use humor in interfaces\nThis 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!\nSo now I’d like to share what I’ve found and hopefully inspire some of you to work on making your users smile.\nI’ll give examples on three ways to use humor in interfaces:\n\nMake errors less frustrating\nMake users smile at details\nConvince users to do something they don’t really want to\n\nLet’s dive in!\nMake errors less frustrating\nOne 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.\nTwitter shows an adorable illustration when it’s down due to overload:\n\nGoogle also uses funny illustrations if there are no results when searching for flights:\n\nSpotify cleverly complements the user instead of just saying “There are no lyrics available for that song”:\n\nMailchimp hints of an evil twin if the username you want is taken:\n\nBasecamp has an illustrated boy pointing to each form field as you fill them in. He turns surprised when you make a mistake:\n\nA 404-page is an awesome place to add some humor. Olivia Ricci exploits every user’s strong feelings for cute kittens. Aww!\n\nWhy do charming error messages works wonders?\nWell, 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.\nIf 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!\nMake users smile at details\nAnother great place to use humor is in the details. Leave small treats for your users!\nThere 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.\nIn Spotify the time bar turns into a light saber in the Darth Vader playlist:\n\nGoogle Hangouts show charming animations when you type certain words, like “Happy new year”:\n\nTumblr changes their wording depending on the age of the user:\n\nA Lego figure covers his eyes when you type your password on Lego Universe:\n\nSiri answers some philosophical questions in clever ways:\n\nGenerally, 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\nMailchimp 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\nIf 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\nHere are some advantages of using humor in the details:\n\nIt makes the interface sharable. The first thing I did when I saw the Mailchimp high five feature was to take a bunch of screenshots and share them with my colleagues on Slack. You’ll get your users to market your product for you. Genious!\nIt makes the user feel special. It’s kind of like finding a hidden treasure! It builds a connection between the user and your brand.\nIt makes users search for more special details in your interface. A quick search on Google and you’ll find tons of funny things to ask Siri. This can help build loyal users who share their findings.\n\nConvince users to do something they don’t really want to\nIncrease 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.\nSongkick 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\nNobody 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\nOkCupid shows this epic banner to people who use ad-blockers to get them to donate.\n\nYou will be much more inclined to do something if you’re in a good mood! That’s the simple brilliance behind this technique!\nStill 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.”\nI 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.\nAs 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!\nCreate memorable experiences\nLastly, 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.\nIn 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:\nPeople\u2019s memories of an experience are based on a rough average of the most intense moment (the peak) and the final moment (the end).\nSo 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.\nYou probably see where I’m going with this!\nHappy 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.\nSpotify cleverly uses humor in their offboarding by offering the user a “Farewell playlist” when they cancel their subscription:\n\nMaybe 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.\nA final joke\nI want to live like I learn! Since the article is just about over, here’s a joke:\nHow many graphic designers does it take to change a light bulb?\nFour. One to change the bulb and three to argue about whether they should have used serifed or sans serifed fonts on the packaging.\nAhh, priceless! If I listen closely, I can just about hear the endorphins flowing through your body helping you remember this article!\nHope you enjoyed!\nThe post Charming interfaces \u2013 make your users smile appeared first on Axess Lab.", "date_published": "2017-09-30T16:26:31+01:00", "date_modified": "2017-10-02T17:40:29+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/09/featured2-2.jpg" }, { "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, intranets 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", "content_text": "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\nAbout the accessibility directive\nIn 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.\nIn 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.\nThe directive in a nutshell\n\nIf you work with web or apps in the public sector, the directive states that you must:\n\nMake sure your website, intranets and apps comply with accessibility standards (more on that later in “What are the actual rules”).\nProvide a feedback mechanism where anyone can notify you of failures to comply with the accessibility standards.\nRegularly provide a detailed accessibility statement on your compliance, using a template from the EU Commission.\n\nWho is affected\nThe 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”.\nSo you’re definitely affected if you \u2013 or your clients \u2013 fulfill the following criteria:\n\nWork with web, intranets or apps\nWork in a public sector body\nWork in an EU-country\n\nEven if you’re not a government organization, you’re still affected by the directive if you:\nProvide services that are essential to the public, or services that specifically address the needs of, or are meant for, persons with disabilities.\nExactly 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.\nThe directive lists some exceptions. The most prominent are:\n\nBroadcasters (TV, radio etc)\nOnline maps\nLive video or audio content\n\nThere are a few other exceptions that you can read about in Article 1 Section 4 of the directive if you’re interested.\nWill they audit me?\n\nYes. Here are some quotes from the directive:\nMember States shall ensure the availability of an adequate and effective enforcement procedure to guarantee compliance with this Directive\nMember States shall periodically monitor the compliance of websites and mobile applications of public sector bodies with the accessibility requirements\nMember 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\nSo to cite George Orwell: “Big brother is watching you!”\nWhat happens if I don’t comply\nThe 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.\nBut 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.\nDeadlines \u2013 How long do I have to comply?\n\n\n23 September 2018 \u2013 deadline for countries to have put laws and regulations in place to comply with the directive.\n23 September 2019 \u2013 all new websites (created after 23 September 2018) need to be accessible\n23 September 2020 \u2013 all websites (not just new ones) need to be accessible\n23 June 2021 \u2013 all mobile apps need to be accessible\n\nThis 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.\nFor 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!\nWhat are the actual rules?\n\nIf you want to dive into the actual standard, you should! But be prepared to do some serious reading.\nThe 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.\nIf 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.\nPractical seven step guide to compliance\n\n“Only seven steps!?” you might be thinking, but it gets even better:\n\nApart from making your site or app accessible to people with disabilities, we guarantee it will become more usable for all your users. Win-win!\nYou might be able to skip some steps, depending on what type of organization you are.\nIf you’re only going to procure apps or websites, you should focus on step 1, 3, 4 and 7.\nIf you’re only building the apps or websites, focus on step 1, 2, 5 and 6.\n\nSo here we go! Our guide for building accessible products that comply with the accessibility directive:\n1. Educate yourself and colleagues\n\nTo 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.\nHere are some key roles and the competences they’ll need:\n\nDevelopers need to learn how to use techniques like WAI-ARIA to make their code accessible to assistive technologies.\nTesters and developers need to learn the basics of assistive technologies like screen readers, so they can validate the user experience of their interfaces.\nDesigners need to learn how to create accessible user experience and design, like how to check the contrasts of their color schemes etc.\nEditors need to learn how to produce accessible content, like how to write alternative texts for images and create captions for videos.\nManagers need to know how to plan for accessibility and incorporate it into their requirements and agile processes.\n\nLuckily, 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.\nIf you don’t have an accessibility professional to teach your team, here are some companies that offer accessibility training:\n\nAxess Lab (yes we shamelessly promote ourselves because we’re really good at this!)\nPaciello Group\nSimply Accessible\nFunka\n\nA 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.\n2. User test\n\nUser 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!\nTrust 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.\nIf 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.\n3. Rework your style guide\n\nI 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.\nUsually 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.\nPut in the effort to rework the style guide once and you’ll see so much fall into place automatically.\n4. Feedback mechanism\n\nThe 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.\nFor 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.\nMany 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.\n5. Automatic testing\n\nThere 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\nHere’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:\nIt\u2019s important that teams don\u2019t rely on them too heavily.\nAutomatic 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.\nHere are some automatic testing tools that you can compare:\n\naXe\nTenon\nSiteImprove\npa11y (free)\nWAVE (free)\n\n6. Manual testing\n\nYou should complement your automatic testing with manual accessibility testing. In other words: let someone who knows about accessibility test your site or app.\nHere, you can either work together with accessibility specialists or educate people in your testing or development teams to do the accessibility testing.\nYou 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.\nA 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.\n7. Procurement and requirements\n\nIf 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.\nJust 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!\nYou 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.\nHigh five!\n\nBy following the web directive and creating accessible websites and apps you’re doing a great thing for democracy and people’s independence.\nWhen 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.\nOn 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.\nThe post Web Accessibility Directive \u2013 What it is and how to comply appeared first on Axess Lab.", "date_published": "2017-09-27T20:27:22+01:00", "date_modified": "2018-09-17T13:59:46+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/09/banner-square.jpg" }, { "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", "content_text": "We often get asked how many people have a disability. So here is everything we think you need to know about the statistics.\n\nYea, that’s it! You really don’t need to go dig into more details than that.\nAccessibility 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!\nBut 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).\nText transcript of the infographic\n100 % of the world population spend part of their life with a disability.\nHere are some examples of why:\n\nBright sunlight on your phone screen leads to vision impairment.\nBig thumb on small mobile device on shaking train leads to motor impairments.\nLoud environment leads to impaired hearing.\nAlcohol leads to lowered cognitive abilities.\nTired or stressed results in lack of focus.\nAgeing leads to all of the above.\n\nAccessibility matters to everyone.\nDesign for all. Always.\nThe post Statistics on disabilities \u2013 the one stat you need to know appeared first on Axess Lab.", "date_published": "2017-09-19T08:42:05+01:00", "date_modified": "2017-09-19T13:39:57+01:00", "author": { "name": "Hampus Sethfors", "url": "https://axesslab.com/author/hampelusken/", "avatar": "https://secure.gravatar.com/avatar/78107d6c74e95c8812698a2de239fe0f?s=512&d=mm&r=g" }, "image": "https://axesslab-9891.kxcdn.com/wp-content/uploads/2017/09/graph-1.png" } ] }