Tag Archives: accessibility

Almost everyone uses the internet. Browsing websites, purchasing products online, checking bank account balances, or just chatting with friends using social media, are activities that sighted people take for granted. But, how would you accomplish these tasks if you were blind?

WCAG is short for Web Content Accessibility Guidelines.
These guidelines were developed through the W3C process with a goal of providing a shared standard for web accessibility that meets the needs for every individual, organization, and government. It covers a wide range of recommended web content to make it easier to browse the internet for people with disabilities. Its success criteria is written as a testable statement that isn’t technology-specific.

CDN is short for Content Delivery Network which is a network of servers that deliver cached static content from websites to users based on the geographic location of the user. A CDN will not take the place of your web hosting account but simply improve website speeds.

Advantages of Using a CDN

When a website has a high volume of traffic then the site can overload the server, which leads to a slow loading site or even server crash. This is where a CDN comes in handy because it is a network of servers, but most importantly these servers are spread throughout the world.

When a CDN is being used, the static content is cached and stored on all of these servers. Static content includes images, stylesheets (css files), javascripts, Flash, etc. When a user visits the site (original server), the CDN technology redirects them to the closest server to their location.

If your website is receiving heavy traffic and you have not yet enabled an CDN here are some good reasons to get started today:

Choosing a CDN That’s Right For You

However, if you are running on a managed WordPress host such as Kinsta, WP Engine, or Pagely you might not want a full blown caching plugin just to enable your CDN. This is where the free lightweight CDN Enabler WordPress plugin from KeyCDN comes into play. Note: You don’t have to be using KeyCDN to take advantage of this plugin. It will work with any CDN provider.

Do you know who Tim Berners-Lee is? If the name sounds familiar it’s because you probably heard the name before. He created the World Wide Web (WWW) and is founder of the World Wide Web Consortium (W3C), an organization that develops technological standards for the Web. He is committed to the ideal that the internet should be available to anyone, anywhere in the world, on any type of machine that has an internet connection.

This includes people with different technology resources, rural users or even people with disabilities which is estimated to be about 1 billion people worldwide.

Barriers

The work of standards organizations help us identify what barriers people face when using the Web. There’s a plethora of information on what Web Accessibility is and what barriers there was to users on the Web. To remove these barriers we must first define what they are. I will focus on three main points that generally define what they are for all users.

Perceivable: The interface and the information on a Web Page must be presented in ways that are perceivable.

Operable: The navigation components and interface must be usable.

Understandable: The user interface and information must be understandable.

Robust: The underlying code and programming is robust, adaptable, and secure.

Along with these main points, there are also four main disabilities that can affect access to the web.

Visual

Text Magnification hardware/software

Relative font sizes

Use of proper CSS

Small or poor contrast text

Color identifying information

Mobility

Limited mobility devices

Mouse typically not an option

Cognitive

Learning disabilities benefit from well designed and organized pages

Auditory

Multimedia barriers to users hard or hearing or deaf

Example

Here is an example of ways to design your image ALT text to remove barriers to disabled users when using screen readers.

Because screen readers cannot interpret the content of images on a web page, the use of “ALT” text helps describe in words to the user what the image content is. Taking the time to accurately describe an image content will greatly help the Accessibility on your site.

If an image is a…

The ALT Text should…

Chart or Illustration

Summarize and explain

Photo or work of art

Describe the image’s content

Graphic or button with text

Be the same as the image’s text

Functional icon without text

Describe the action to be taken

Background or other decoration

Contain an empty space (” “)

Although, ALT Text is meant to be short and concise, when longer descriptions are used to explain or describe an image it can be very helpful in breaking down the Web Accessibility barriers to users on your site.

Standards in Accessibility on the Web

As the we move forward in developing web standards and adhering to those standards, we help define what barriers users experience in terms of Accessibility when using the World Wide Web. Organizations helping pave the way for these standards are helping remove barriers to users across the world by evaluating the needs of users from all demographics.

For more information on related articles and resources used in this article:

When designing websites it is imperative to follow the necessary standards to design a site that is safe for those who suffer from photosensitive epilepsy or other seizures.

Photosensitive epilepsy is a form of epilepsy in which seizures are triggered by visual stimuli that form patterns in time or space, such as flashing lights, bold, regular patterns, or regular moving patterns.

HTML5 has improved greatly over the years. One of its biggest successes was trying to make the World Wide Web more accessible by moving in a more semantic direction. It introduced several new semantic elements such as: <section>, <article>, <aside>, <hgroup>, <header>, <h1> through <h6> level headings, <footer>, and <address>. While these new elements are great, they don’t actually do anything.

They crack the door open slightly to provide value to assistive technologies that can expand upon the elements through programming. These new elements have been made standards by W3’s Consortium. While these are made standards, not everyone is required by law to follow them. The biggest problem with HTML5 and its accessibility features is the compatibility of the browsers that interpret the markup. Most development companies follow these standards but they are free to take their own direction when building a browser.

Accessibility and Compatibility

HTML5 has great accessibility features but there are still some issues. Because HTML5 is constantly evolving, it makes it difficult in the development stages. Here are some of the current issues:

Competing video formats are making HTML5 based video playback almost impossible to implement

Inconsistencies between web browsers

The heading structure is not useful in assistive devices

Interpretation and support among technology products

One of the top browsers that has kept current with the evolution of HTML5 is Mozilla’s Firefox. This screen shot shows which major browsers support HTML5 accessibility attribute features:

The ARIA

Every developer and designer should ensure their website covers as many disabilities as possible to provide users with a rich accessible experience. That’s where ARIA (Accessible Rich Internet Applications) or WAI-ARIA comes into play. ARIA defines the roles, names, descriptions, values, and states of objects to help assistive technologies, such as screen readers to better understand the information laid out on the page.

ARIA When and How

ARIA has a wide range of accessibility elements. For that reason we will only be covering a few examples in this section. The elements that will be explained are better known as the “Landmark Roles.”

The document Role

The document role helps assistive technologies switch from normal browsing mode into a mode more suitable for interacting with web documents. Most webpages are considered a document because you often read them, while a document role still supports users to have interactions. This is often inserted into the body element.

<body role="document">...</body>

The banner Role

The banner role should only be used once within the html markup. It is usually used within the top of the page in the <header> or any element that contains the prime heading or in-page title of the site.

<header role="banner">...</header>

The complementary Role

The complementary role is generally used in the <aside> or sidebar section of the HTML document. The complementary role element lets assistive technologies know that whatever is inside this area, it is complementary to the main content.

<aside role="complementary">...</aside>

The contentinfo Role

The contentinfo role is used within the area that contains copyrights and links to privacy statement information. It is generally used in the <footer> element of your markup.

<footer role="complementary">...</footer>

The form Role

The form role is used by a screen reader to let users know that they can fill out a form. On some screen readers, users have quick keys to direct them to this sections of the page quickly. There is a lot more that goes into forms and it is recommended that you read the help documentation provided by W3.

<form role="form">...</form>

The main Role

The main role in ARIA is better explained as the most important element for screen readers and users alike. It is essentially used a link to “Skip to the main content”. It helps users know that this is what they are essentially looking for on a page.

<section role="main">...</section>

The navigation Role

The navigation role element is used in the navigation or <nav> element. The most important thing for any website is to be able to clearly navigate it. The navigation role tells screen readers that this is your navigational links.

<nav role="navigation">...</nav>

The search Role

The search role tells assistive technologies that users can search the website through this section. It is often used in a text input field labeled with role search.

As of 2013, we have an estimated 2.7 billion users on the internet, which is nearly 40% of the entire human population (7.3 billion, as of July 2015). Of those users, only 1.8 billion are connecting to the internet at broadband speeds (this includes both land-line and mobile broadband connections). With web pages becoming more and more data heavy, thanks in large part to Plugins, large images and videos becoming common content, the 33% of internet users who have connection speeds under 150 kbits/s are at a major disadvantage when it comes to accessibility.

So what can you, as a developer, do to better serve the lower third of internet users who suffer from low connection speeds? Well, Aptivate has already put together a very comprehensive guide to developing with low-bandwidth users in mind, so in this article, I’ll just be reviewing the most important aspects of their approach.

Size Matters

One of the main points that you must be aware of when developing for low-bandwidth users, is to keep the total size of a page (including all HTML, Javascript, CSS and images) under 25kB. I know that this may not sound achievable in some situations, but in the modern age of design, minimalist structure and design is not only good for low-bandwidth users, but also for all users in general.

After all, when users arrive at a page that has too much (or too little) information displayed on a single page, they are likely to leave. This requires designers and developers to work hard at distilling the raw idea of what you need to convey to users on your site, instead of just filling your site with content.

A Picture Takes as Long as 1000 Words

Though this metric isn’t completely accurate, the message is this: If you can convey a message with words, instead of pictures, always use words. When you do have to use a picture, have it in the correct format to reduce size, and if the image is very large, consider using a thumbnail that links to the full-size image. This way, the user isn’t forced to download those large images when your page loads initially.

Cache and Inform

Allowing your site to be cached enables users to save duplicate content (like images) so they don’t have to re-download that content each time they visit your page. There are several techniques that you can utilize for this, and the full guidelines go over those techniques in their section about caching.

Lastly, it’s best to warn users of page sizes when you link to them. This way, they can decide whether or not they want to follow the link. For example, if you provide a link to a chart that details more about the subject you are talking about on your site, a user would probably be very interested in the link. However, if that chart is a 20MB image, the user may want to know that before they prepare for the 5-minute or more download time that it will take to access the information.

Additional Resources

More information on this subject can be found in thew following locations:

The objective of this technique is to give each Web page a descriptive title. Descriptive titles help users find content, orient themselves within it, and navigate through it. A descriptive title allows a user to easily identify what Web page they are using and to tell when the Web page has changed.W3C Working Group Note

Having a descriptive title for web pages is vital for many reasons, but according to the W3C Working Group Note, it is especially important in regards to web accessibility practices and guidelines.

According to Wikipedia, Web Accessibility refers to the inclusive practice of removing barriers that prevent access to websites by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality.

We are all aging. That’s an undeniable fact. In the 2013 United Nations World Population Aging report their studies showed that every country in the world is experiencing a shift to a larger population of older citizens. Generally this happens when mortality rates decrease and fertility rates decline.

In other words less people die and less people are born. That changes the ratio of young people to older people and creates what is known as an aging population.

The criteria for presenting small flashing objects and text on a web page varies depending upon the reference you use when it comes to defining what amount of flashing and moving is permitted on the web within the web accessibility laws. Of course, this changes depending upon which country’s laws are being followed as well.

The important point to consider is that you don’t let small flashing objects flash faster than 3 times per second. According to W3C.org:

The criterion is 25% of any 10 degree visual field, any single flashing event on a screen (there is no other flashing on a screen) that is smaller than a contiguous area of 21,824 sq pixels (any shape), would pass the General and Red Flash Thresholds.

That is an image the size of 341 x 246 pixels. The definition of a “general flash” or a “red flash” are defined below in the threshold definition by WCAG 2.0 Recommendation as:

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

there are no more than three general flashes and / or no more than three red flashes within any one-second period; or

the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

The definition of small enough is given as “25% of any 10 degree visual field on the screen… at typical viewing distance”. This size, therefore, depends on the screen size, resolution, and viewing distance. The higher the resolution or screen size, the larger the permitted area.

Objects that flash and blink on the web page run the risk of initiating optically-induced seizures in visitors. According to WebAIM, no element should flash at a rate of 2 flashes per 55 cycles per second. Using their 508 checklist, one or more elements that flicker on a page that does not meet this criteria is considered to fail, and will put someone at risk who is sensitive of optically-induced seizures.

Three Flashes or Below Threshold: web pages do not contain anything that flashes more than three times in any one second period.

The intent is to reduce the chance of seizures since some people are sensitive to flashing on screens. This includes people with photosensitive epilepsy as well as photosensitive seizure disorders.

W3C goes on to further explain this is detail so that a writer could fully understand how critical it is to make sure accessibility standards are met. The other resources all show that optical seizures are the main reason why that this criteria is maintained. These sources differ in the timing of the flashing time limit but they agree about the results. So whatever source you choose consider your reader.

The web standards for moving and flashing text for web accessibility are found in Section 508 1194.22 (i), WCAG 1.0 A 7.1, and WCAG 2.0 A 2.3.1.

When you click a link on a website, what is that link? What is it made of? The W3schools website defines a link as “a link between a document and an external resource.” A link is basically an established relationship between one document (HTML, CSS, etc.) and another. A link is one of the many roads to travel on the World Wide Web.

While links are easy to include in a Post or Page, they are too easy. In fact, it is not hard to overlook a very important part of links: web accessibility. According to the W3C Web Accessibility Initiative, web accessibility is defined as an initiative to help “people with disabilities” navigate, use, and contribute to the web. Despite the fact that the initiative is mainly for people with disabilities, web accessibility also helps people without disabilities:

Web accessibility also benefits people without disabilities. For example, a key principle of Web accessibility is designing Web sites and software that are flexible to meet different user needs, preferences, and situations. This flexibility also benefits people without disabilities in certain situations, such as people using a slow Internet connection, people with “temporary disabilities” such as a broken arm, and people with changing abilities due to aging.W3C Web Accessibility Initiative

Video Captioning allows the content of web audio and video to be accessible for those with disabilities. It can also be useful for those who are not fluent in a language in which the audio is presented. Video Captioning is not only essential for people to understand your content, but it’s also required by law. Continue reading Web Accessibility: Video Captioning→

In our contemporary tab centric browsing experience —where tabs have become all but common place for navigating the web, it might appear helpful to provide your user a new tab for opening external content, thus saving them the task of pressing the back button to return to your site, but this is not always the case.

POUR Guidelines and Accessibility

The POUR guidelines were defined under the Web Content Accessibility Guidelines 2.0 specification which was drafted by the W3C in 2008. POUR stands for Percieveable, Operable, Understandable, and Robust. Opening links in new tabs infringes on the second principal of Understandability, which states that websites should operate in easy to understand and predictable ways.

Imagine for a moment that you are a blind user using a screen reader to navigate content when you arrive at a link midway down the page, as soon as you click on the link a new tab appears beside your current window without you knowing and you are left wondering where your content is. As you can imagine this can be a very disorienting experience for blind clients using your site. This particular point is specifically addressed by the W3C Content accessibility guidelines.

UX Considerations

Opening links in news tabs also takes away control from the users by eliminating their ability to choose how links open. In the Smashing Magazine article “Should links open in new windows?” Vitaly Friedman states that:

Users need to be able to rely on consistency of the user interface and know that they won’t be distracted or disrupted during the interaction. Users must know, understand and anticipate what is going on and what will happen once user interface elements are used. Any deviations from this convention result in a more design-oriented and less user-oriented design.

By dictating to users how their browsers ought to behave you rob them of the freedom to decide how they want to navigate the web.

Setting Link Behavior in WordPress

Now that we’ve discussed why you shouldn’t open links in new tabs, lets discuss how to set link behavior so that we can avoid this problem altogether. In WordPress you set link behavior on a post by post basis and must set the behavior for each link included in your post. To set link behavior we must first create a new link:

1. First highlight the text you would like to link to.

2. Then press the link icon on the visual editor.

3. In order to set link behavior look for the check-box under the title text field. By default this should be unchecked. Unchecked means that the link will open in the current tab, this is the behavior that we want.

4. Make sure that the check-box remains unchecked.

5. Click update at the bottom of the window when you are done.

Please note that this tutorial is specific for WordPress, other web publishing platforms will require different steps.

For further discussion on the practice of opening new links in tabs please visit:

Posts navigation

Welcome to the class site for the WordPress classes at Clark College in Vancouver, Washington. All content is created by the students and instructors writing about WordPress, offering WordPress tips, techniques, and helpful information as part of their class assignments. Student discussions are held on ClarkWP Talk. Please see our About, Contributors, and Policies for more information.

Students Serving Up WordPress Tips and Techniques for Clark College Students and the World

Welcome to ClarkWP Student Site

Welcome to the class site for the WordPress classes at Clark College in Vancouver, Washington. All content is created by the students and instructors writing about WordPress, offering WordPress tips, techniques, and helpful information as part of their class assignments. Student discussions are held on ClarkWP Talk. Please see our About, Contributors, and Policies for more information.

Welcome to the Clark College student-run WordPress site. This is a class project for the WordPress and related courses offering articles by the students on WordPress and web publishing news, tips, techniques, and commentary.

Many of the articles are graded class assignments, but many are self-assignments by the students.