Category Archives: web

WCAG – Quick Facts and Guide – Hurix Digital

This is how WCAG guidelines help.

The standard Web Content Accessibility Guidelines (version – WCAG 2.0) is a set of rules that defines how to make web or online content more accessible, especially to people who are differently-abled. ‘Accessibility’ here could involve a wide range of limitations, including visual, auditory, physical, speech, cognitive, language, learning, and neurological.

What is it?

The Web Content Accessibility Guidelines (WCAG) are part of a series of web accessibility guidelines

Who is it by?

It is published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)

In short: These guidelines form the main international standards organization when it comes to the matter of content for the Internet.

Why is it pertinent to follow WCAG guidelines?

Implementation of the WCAG guidelines helps maintain a standard quality of online content that is inclusive and serves the interest of readers with different kinds of special needs. Making a particular brand’s online content WCAG-friendly is required to showcase that you have an ‘inclusive mindset’ as a brand.

Some industries may benefit more by following WCAG norms. Those in e-tail / FMCG / e-learning might experience an increased customer base when they follow inclusive norms.

 

Curated by (Lifekludger)
Read full article at Source: WCAG – Quick Facts and Guide – Hurix Digital

HTML For Screen Readers – Labelling Elements

To screen readers, a lot of the visual information that is presented on a webpage is lost. Because of this, we need to specifically provide information to them that may be obvious to a person looking at the page.

One common way people define information specifically for screen readers is to wrap the descriptive text in an element with a particular class, such as .screen-reader-text, and hide the element using a method that keeps it visible to screen readers.

Although this does work, we can use ARIA attrib…

Curated by (Lifekludger)
Read full article at Source: HTML For Screen Readers – Labelling Elements

An Introduction to the Reduced Motion Media Query | CSS-Tricks

A brief history of Reduced Motion

When it was released in 2013, iOS 7 featured a dramatic reworking of the operating system’s visuals. Changes included translucency and blurring, a more simplified “flat” user interface, and dramatic motion effects such as full-screen zooming and panning.

While the new look was largely accepted, some people using the updated operating system reported experiencing motion sickness and vertigo. User interface movement didn’t correspond with users’ feeling of movement or spatial orientation, triggering the reported effects.

Although technology unintentionally inflicting adverse effects has existed before this, the popularity of iOS gave the issue prominence. Apple has great support for accessibility, so an option in the operating system preferences to disable motion effects for those with vestibular disorders was added in response.

#Enter a new media query

Safari 10.1 introduced the Reduced Motion Media Query. It is a non-vendor-prefixed declaration that allows developers to “create styles that avoid large areas of motion for users that specify a preference for reduced motion in System Preferences.”

The syntax is pretty straightforward:

/* Applies styles when Reduced Motion is enabled */
@media screen and (prefers-reduced-motion: reduce) { }

@media screen and (prefers-reduced-motion) { }

Safari will parse this code and apply it to your site, letting you provide an alternative experience for users who have the Reduced Motion option enabled.

Curated by (Lifekludger)
Read full article at Source: An Introduction to the Reduced Motion Media Query | CSS-Tricks

ARIA Labels and Relationships  |  Web  |  Google Developers

using aria-label to identify an image only buttonLabels

ARIA provides several mechanisms for adding labels and descriptions to elements. In fact, ARIA is the only way to add accessible help or description text. Let’s look at the properties ARIA uses to create accessible labels.

aria-label

aria-label allows us to specify a string to be used as the accessible label. This overrides any other native labeling mechanism, such as a label element — for example, if a button has both text content and an aria-label, only the aria-label value will be used.

You might use an aria-label attribute when you have some kind of visual indication of an element’s purpose, such as a button that uses a graphic instead of text, but still need to clarify that purpose for anyone who cannot access the visual indication, such as a button that uses only an image to indicate its purpose.

Curated by (Lifekludger)
Read full article at Source: ARIA Labels and Relationships  |  Web  |  Google Developers

Using Keyboard-only Navigation, for Web Accessibility

Blind and low-vision users, as well as those with mobility disabilities, rely on their keyboards — not a mouse — to navigate websites. Online forms are keyboard "traps" when they don't allow a user to tab through it without completing a field. That is not the case with Newegg's checkout form, which properly allows users to tab through it, and ultimately return to the browser bar, without completing a field.

… Programmers are big fans of using the keyboard instead of continually shifting between the keyboard and mouse.

And yet a significant percentage of websites make it difficult or even impossible for users to perform some activities without using a mouse or other pointer device. This curious relationship between using the keyboard and developing for the keyboard has always seemed imbalanced to me.

To be fair, navigating the Internet with a keyboard is very different from using a keyboard shortcut to perform a complex task.

The keyboard shortcuts that people use with most desktop software are combinations of two to four keys that directly activate menu actions buried somewhere in the program’s options.

Navigating a website with the keyboard primarily requires only a few keys, but they’re used constantly. The following keys are most fundamental to using a website.

  • TAB
  • SHIFT+TAB
  • SPACE
  • ENTER
  • The left, right, up, and down arrow keys.

In complex web applications, like Google Docs, more complex keyboard shortcuts are common. But for an average ecommerce site — where the priorities are getting the user to find a page, learn about a product, and then go through the purchase process — those keys are usually all you need. These are the keys that are natively defined by browsers for the operation of web pages.

Why Navigate with Just a Keyboard?

 

Curated by (Lifekludger)
Read full article at Source

Sounding out the web: accessibility for deaf and hard of hearing people [Part 2]

[Part 2]

In my previous post, I spoke with Ruth MacMullen, an academic librarian and copyright specialist from York, about her experience of being deaf and how it affects how she uses the web. In this next post in the series, Ruth shares some of the things that make life easier for her on the web, and we offer some practical tips on how you can improve accessibility for deaf and hard of hearing people.

Provide subtitles/captions

The YouTube video player showing a video about York St John University with closed captions switched on. The captions are displayed over two lines with the end of the sentence cut off.“Subtitles, that’s the really obvious one”, remarks Ruth as we discuss the things that help her the most. In my previous post, she described the frustration of viewing a video posted on Facebook that lacked subtitles.

Subtitles or captions are the words shown at the bottom of videos that explain what’s being said or what’s happening. The term “subtitles” typically refers only to spoken content, whereas “captions” also includes descriptions of non-speech sounds, such as music, applause and laughter. Outside of North America, the terms are often used interchangeably. So when Ruth refers to subtitles on videos, that’s what she’s talking about.

Curated by (Lifekludger)
Read full article at Source: Sounding out the web: accessibility for deaf and hard of hearing people [Part 2] | The Paciello Group – Your Accessibility Partner (WCAG 2.0/508 audits, VPAT, usability and accessible user experience)

Reframing Accessibility for the Web · An A List Apart

We need to change the way we talk about accessibility. Most people are taught that “web accessibility means that people with disabilities can use the Web”—the official definition from the W3C. This is wrong. Web accessibility means that people can use the web.  Not “people with disabilities.” Not “blind people and deaf people.” Not “people who have cognitive disabilities” or “men who are color blind” or “people with motor disabilities.” People. People who are using the web. People who are using what you’re building.We need to stop invoking the internal stereotypes we have about who is disabled.

We need to recognize that it is none of our business why our audience is using the web the way they’re using it.

We can reframe accessibility in terms of what we provide, not what other people lack. When we treat all of our users as whole people, regardless of their abilities, then we are able to approach accessibility as just another solvable—valuable—technical challenge to overcome.

Curated by (Lifekludger)
Read full article at Source: Reframing Accessibility for the Web · An A List Apart Article

Defining and Measuring Usability and UX. The Big Difference Between Usability and UX

Everyone knows that user-friendly websites and apps are vital for the overall success of a business. We know that design quality indicates credibility and trust and that those things drive results.

We know this.

So how do you know that your site or app is easy to use? What steps do you take to know for sure that your design is driving those results?

This guide will define what usability and UX are (as these terms are often confused) and this guide will also show you how usability and UX can be measured.

Ready? Let’s get started.

Usability is Not UX

We hear the terms often: usability, UX but let’s admit it – although we know they are both important in the design world, we often confuse them.

Usability is about task-based interactions such as navigating a site, filling out a form, checking out at an online store, etc. It’s the ability to do something intuitively and easily.

UX is about how a person feels when they interact with your site or app. Are they encouraged to sign up to your newsletter? Are they moved by the design in the front page? Is the copy engaging or dull?

Let’s dive into some of the details.

What Exactly is Usability?

Designers, developers, and usability experts have racked their brains trying to define usability. The truth is, there is not a universal definition. There are many books and resources on the topic and not one of them is the same.

Jakob Nielsen describe usability with these five qualities or as he calls them, “Usability Goals.”

  1. Usefulness. Although it may seem obvious, you should always be curious and ask: Is this feature useful? Is it redundant? Will it help the user accomplish a task?
  2. Learnability. When a new user comes to your website or app, you want them to easily learn how to get around. What are you doing to make this happen?
  3. Memorability: When users return to the design after a period of not using it, will they remember it?
  4. Errors: What happens when uses make an error? How many errors do users make, and do they eventually find a solution?
  5. Satisfaction. How pleasant is it to use the design? Are users sharing the website? Have you delighted them or did the whole experience cause them frustration?

How Do You Measure Usability?

Source: Defining and Measuring Usability and UX. The Big Difference Between Usability and UX

10 guidelines to improve your web accessibility

We put together a list of ten web accessibility guidelines that will guarantee access to your site to any person, in spite of their disabilities.

There’s a quote by Tim Berners-Lee, Director of W3C and inventor of the World Wide Web, that says, “The power of the web is in its universality”. As people who make a living by making websites, it’s our responsibility to ensure everyone has access to them. Web accessibility seems like a tall order on paper, but it’s definitely much easier than it sounds.

Our ten web accessibility guidelines are designed to ensure that all websites are universal.

This will not only help screen reader users, but will also improve browsing experience for slow connections. We’ve sorted our guidelines by implementation time to give you a clear picture of just how much effort you’ll have to put into this process. Before you get overwhelmed, take our word for it—it’s totally worth it.

First things first:

Curated by (Lifekludger)
Read full article at Source: 10 guidelines to improve your web accessibility | Aerolab

Accessibility Testing: Checkers & Development Tools Review

Tools of the Trade

In a different article, I outline the basics foundations of accessibility standards: “Understanding s508 & WCAG 2.0“. To further expand this, let’s look at various development tools to help author accessible content conformant to the Web Content Accessibility Guidelines (“WCAG”) 2.0 standards.

Getting Started

For a primer or refresher on what the Web Accessibility Initiative (WAI) is review the W3 Org website and its associated entries on this subject at https://www.w3.org/WAI/.

Checkers and Tools

W3 Org offers a great list of available tools for developers to use when checking content for accessibility conformance at https://www.w3.org/WAI/ER/tools/. Various filters can be applied to this list, in order to narrow-down best options. For this article, I applied the following filters:

  • Guidelines > WCAG 2.0 – W3C Web Content Accessibility Guidelines 2.0
  • Languages > English
  • License > Free and License > Open Source

From the filtered-list, I chose to explore the following tools/checkers:

Curated by (Lifekludger)
Read full article at Source.