Month: September 2018

By Sam Stemler on Sep 25, 2018

For web accessibility—making the World Wide Web equally accessible for all users, regardless of physical or cognitive ability—WCAG 2.0 by the World Wide Web Consortium (W3C) is the gold standard. Its AA level of compliance is the main reference point for accessibility standards the world over, including the United Nations, European Union, and the United States, among others. However, WCAG 2.0 was published in 2008, and the web has changed dramatically in 10 years. WCAG 2.1 began in 2017, with the latest update (as of this writing) published in June 2018. WCAG 2.1 addresses changes to the web, and how new technologies can be implemented so all users have equal access. In this blog, we’ll explain the key differences between WCAG 2.0 and WCAG 2.1., and what they mean for your site or app.

Key Differences Between WCAG 2.0 and WCAG 2.1

What is WCAG 2.0 and WCAG 2.1?

The Web Content Accessibility Guidelines, also known as WCAG, version 2.1 builds on WCAG 2.0, but it is not meant to replace it. WCAG 2.1 gives content producers, web developers and other stakeholders the most recent web accessibility guidelines, in order to resolve questions about new technology.

According to W3, a larger-scale update is currently in review, most likely titled WCAG 3.0. W3.org explains, “This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0.” The 3.0 guidelines yet to come will build from the most recent current guidelines, so users and developers who are up-to-date with WCAG 2.1 will more easily transition to WCAG 3.0, which may replace WCAG 2.0 eventually.

There are 17 differences between WCAG 2.0 and WCAG 2.1. The scope of this blog is limited to significant changes likely to affect many websites and only those concerning A or AA level compliance, which is used for most rule-making, such as Section 508 and ADA compliance. For a full list and further explanation of changes, see WCAG 2.1 section 0.5.1

1. Orientation: Landscape or Portrait Interchangeable

This difference between WCAG 2.0 and 2.1 mostly concerns tablets and mobile devices, which now accounts for the majority of web searches. When users flip a device, such as a tablet or smartphone, the orientation switches between portrait and landscape. However, some users cannot flip their device, such as devices mounted on power wheelchairs. To address this, websites should be equally accessible in either orientation. You can test this by simply accessing your site on a mobile device and flipping the device. If it doesn’t flip or if functionality is limited in one orientation, you’ll need to take a closer look at your CSS code.

2. Reflow: Magnification and Mobile Usability

Reflow capabilities are essential for sight-impaired users, which may include elderly users with deteriorating vision, users with certain conditions like cataracts, or nearsighted people without glasses or contacts. When reflow is enabled, it reorganizes the site when users zoom in. This makes text and pictures easier to see, without creating distortions or disrupting page navigation. Reflow also reorganizes pages when screen sizes change, such as between desktop and mobile devices. This makes reflow ideal for mobile page design as well. If you use a responsive web page design, as many accessible WordPress themes are, your site most likely already uses reflow. You can also create an alternate mobile version of your site with a fixed 320 pixel wide layout.

3. Content on Hover or Focus: Essential for Equal Navigation

This difference between WCAG 2.0 and WCAG 2.1 mainly has to do with navigation menus. Remember that many users navigate websites using a keyboard, which allows them to click between links. This means, if your navigation menus are only viewable when you hover over them with a mouse, and disappear otherwise, your site will not be usable to anyone not using a mouse. Allowing menus to display on hover or click can solve this problem. However, an additional click should allow the user to dismiss the menu, as a dropped menu can obscure the page when using a screen magnifier. Many accessible web page themes will already have this capability, and others can be changed with CSS code.

4. Label in Name: Accuracy for Screen Readers

Screen readers tell users how a site is organized by reading programmatic labels, also called Accessible Names. For a screen reader to be able to tell a user what a button, list, new menu, image, or search bar is and what it does, it needs a Accessible Name. This also allows a user to give spoken commands to assistive technology using Accessible Names. Often, web elements are also visually described by text, such as “Request a Quote” for a button or “Search” for a search bar. The label in name requirement in WCAG 2.1 requires the Accessible Name and the visual label of key elements to be the same, so those using screen readers and spoken commands can accurately interpret and interact with the site. Adding label properties to key elements will account for this difference between WCAG 2.0 and WCAG 2.1.

5. Status Messages: Telling What’s Happening

When you add an item to your shopping cart, submit a search on a website, fill in form fields, submit a form, or run an application, among other things, a change occurs showing what you did. You will see that your shopping cart now has another item, that your form fields were or weren’t correctly filled in, that your form was or wasn’t successfully submitted, or that the application you clicked is running. You don’t need to click or scroll over anything to see these messages. This WCAG 2.1 criterion addresses these messages for screen readers, allowing users to hear status changes when they occur. Similar to labels above, this can be accomplished by adding roles or properties to status messages. With the right roles and properties designated, screen readers will announce status changes.

These key differences between WCAG 2.0 and WCAG 2.1 are intended to keep accessibility guidelines evolving as technology evolves. With a few lines of code in integral places, you can ensure that all users can use your website equally. To see if your website stacks up to these changes and is accessible to all users, run a test. Automated or manual testing will reveal key issues in your site’s accessibility that traditional usage with a mouse and interface can’t.

By Sam Stemler on Sep 7, 2018

An estimated 30% of the entire world wide web now runs on WordPress. When it comes to making the internet accessible for all users, WordPress plays a big part. WordPress caters to advanced web developers as well as beginners, so many users are approaching the concept of online accessibility for the first time. We’ve broken WordPress accessibility down to its basic elements and provided some resources to help users at all skill levels, with all types of sites.

The Basics of Web Accessibility

What is Accessibility?

You probably already know that web accessibility means making your website accessible to all users, regardless of their motor skills, sight, hearing or the hardware they use, such as assistive technology. Though there are many aspects of this, accessibility for most WordPress sites applies in three major ways; content, design, and navigation.

The Worldwide Web Consortium (W3C), an international group of experts providing best practices and policies for a usable and efficient web, authored guidelines that have become the gold standard for web accessibility across the globe. These standards evolve as technology evolves and address many parts of computing, but the most relevant current standard for web authors is the Web Content Accessibility Guidelines Version 2.0 AA (WCAG 2.0 AA). Many countries, including the U.S., use WCAG 2.0 AA as a baseline for legal cases and regulations concerning web accessibility.

Organize your WordPress website accessibility step by step. Download the Ultimate Web Accessibility Checklist >

What Are the Rules for Website Accessibility?

The web is vast network of different technologies that are constantly changing, and making one simple rulebook for the entire Internet wouldn’t work, nor would it allow for much creativity or innovation. Recognizing this, the W3C compiled different guidelines for different technologies and gives web developers the freedom to implement these the best way they can. All of W3C’s guidelines, including WCAG 2.0AA, are about what accessibility should do and look like, not explicitly how to do it.

Though this allows for freedom and growth, it leaves many site managers confused about how to actually implement accessibility. As you go through this WordPress accessibility roadmap, remember that accessibility is about function, not necessarily form. In general, your site should be well organized, understandable, and easy to navigate. These features will benefit all your site visitors, including those that use the web in the traditional way.

5 Steps to WordPress Accessibility

Step 1: Design Layout

The design of your site will play a big role in WordPress accessibility. This decides how users understand and navigate all the content on your site. Your design will decide where the parts of your site are placed, like your navigation menus, headings, icons and text, as well as how they work.

WordPress sites are built around themes, and starting with a theme that is certified accessible will make the rest of your design much easier. These WordPress accessibility-ready themes are built by the WordPress community, and audited for accessibility. Though WordPress bases these audits on WCAG 2.0 AA, they are not necessarily compliant with the Americans with Disabilities Act (ADA) or Section 508. Also, keep in mind that the changes that you make to suit your needs and preferences must also be accessible for the site to stay that way.

The following are common WordPress accessibility concerns in design and layout:

Menus: menus must be navigable without a mouse. Remember that many people cannot use a mouse or see the screen, and instead use assistive technologies that work similarly to keyboards. For example, if your navigation menus only display when a user hovers over them with a mouse and cannot be accessed with a keyboard, the menu is not accessible. Accessible themes contain code that make them easily navigable with a keyboard or similar device.

Buttons and Links: buttons and links should also be recognizable and usable with assistive devices. If a screen reader or another assistive device cannot recognize or “click” a button or link, the user cannot access that information. Accessible themes use proper formatting to make these readable with assistive technology.

Color Contrast: Color schemes are the most common element changed in the theme, but take care to maintain a necessary level of contrast. Consider your text, background, menus, links (including clicked and unclicked) etc. For most parts of your site, your color contrast should be about 4.5:1. This has more to do with the contrast between lightness and darkness than the contrast between colors themselves, as many uses cannot distinguish between certain colors. If you’re not sure, this color contrast checker tool can help.

Step 2: Organization

How navigation menus, text, pictures, banners, and other elements are arranged on a page and how pages are arranged on your site decide how users interpret the information. Proper organization of the site is essential for keyboard navigation and for screen readers.

The theme that you choose will give you a starting point for arranging the elements of your site, but users mostly determine this individually as they build pages. For example, you probably won’t change where your navigation bar exists, but you must decide which pages appear in the navigation menu. Though you won’t change where most of the text appears on your site, you can decide how that text is organized.

These are some common organizational concerns when it comes to WordPress accessibility.

Navigation Menus: Not all pages in larger sites will appear in the navigation menu. To reduce confusion, it’s ideal to organize pages in more than one navigable way. Use a table of contents page, updated sitemap, or a search bar to add other navigation options.

Headings: Without proper page headings, it’s difficult for some users to tell what a page is about. Proper page headings are also an important part of search engine optimization (SEO), so this WordPress accessibility update has multiple benefits.

Section Divisions: Divisions between sections should be clearly marked using HTML or CSS values, otherwise screen readers will not interpret them correctly. If you are comfortable with the code behind your site, set off sections divisions with HTML or CSS. If not, use blocks to divide sections as you construct the site on the front-end. Don’t use paragraph breaks or indents to divide sections, as screen readers interpret these characters in specific ways.

Step 3: Text

At this point, you’ve made your site navigable for all users, and organized it in a usable and sensible way. The text on your pages, including your main pages as well as pages you add regularly, such as blog posts, should also be accessible. Keeping a few guidelines in mind will help you maintain accessibility as your site grows.

Headings: Linear headings help users understand text, even if they can’t see it. Use headings only to organize text in a linear way (H1 headings at the top as main concepts, H2 headings denoting more specific concepts, and so on) and not for emphasis. Avoid skipping headings or using them out of turn.

Lists: Denote lists using the list function, either a numbered list or a bullet list. Screen readers can interpret these as lists, but will not interpret separated paragraphs, tables, or whitespace the same way.

Links: When putting links in your text, make sure the text accurately describes where the link goes. For example, the following text accurately describes a link to the WordPress Accessibility Handbook.

Step 4: Pictures and Media

With your design, navigation and your text in place, you’ll want to add some pictures and media. These elements can be especially challenging for some users. However, keeping WordPress accessibility best practices in mind, you can avoid these problems.

In general, your pictures, videos and other media should not interrupt or interfere with the function of your site. The following are some common considerations:

Alt Text: Pictures should include relevant alternative text (alt text) descriptions. This can also help with SEO.

No Automatic Play: Videos and music should not play automatically and users should be able to start and stop the media at any time. This is an especially important consideration if you are showing ads on your site.

Video Captions: Many people cannot hear the words and sounds in a video. YouTube and other media players offer closed captioning for their videos, but it’s also helpful to provide these yourself to ensure accuracy.

Flashing: No element on your site should flash more than three times a second. This is not only distracting, but it is a hazard for people with seizure disorders.

Interruption: If an ad, pop-up, video or another element blocks a page, a user should be able to remove it with a keyboard the same way as a mouse. Be careful of “keyboard traps,” which allow a user to navigate to a button with a keyboard, but not away from it.

Step 5: Test

The best way to see if your site is actually accessible is to test it. You can perform some of these tests yourself. Though this may be a challenge since you are not used to using websites this way, it should not be overly frustrating. If it is, or if there are things you simply can’t do on your site, it is probably not accessible.

Choose goals and paths that your site visitors would normally take, such as finding a particular page or filling out a form, and conduct the following tests:

No Style Sheets: Style sheets are CSS files that determine many visual elements of your site. Screen readers can’t interpret style sheets. If you turn these off and you can’t use the page, neither can anyone using a screen reader. You can disable style sheets using a specialized plugin, or in the View or Menu options in Firefox or Safari.

No Mouse: Many assistive devices function similarly to a keyboard, so using your keyboard to navigate your site can help you assess accessibility on WordPress. You don’t need any technology, plug-ins, or add-ons to try this. Starting at browser address bar, use Tab to move through links, buttons and form fields, Shift+Tab to go back, and Enter to click. Can you use and interact with your site? Is it overly difficult or tedious? Make changes that would make the site more navigable, such as moving the most important links closer to the top.

No Images: In the tools or settings menus, you can tell most browsers not to load images. You’ll still see the alt text behind them, but not the image itself. Can you still navigate your site? Does it make sense? If important elements are contained in images without the right alt text, this isn’t accessible.

With WordPress supporting so much of the web, accessibility on the platform has become essential. Luckily, WordPress accessibility doesn’t have to be complicated. As the interconnected users continue to develop new, accessible themes, plugins and other features, this will become even easier for users and webmasters alike.

Note: This post is intended to help users implement general accessibility on WordPress sites. It is not legal advice for ADA or Section 508 compliance.