Category: Uncategorized

By Erica Statly on Oct 23, 2018

Web accessibility is important because it guarantees that the internet will be accessible to everyone, regardless of any disabilities. It is a way of ensuring that those who have vision impairment, hearing impairment, learning disabilities, limited movement, speech disabilities or photosensitivity can still easily and equally access websites. In order to make this happen, it’s important to keep accessibility standards in mind and design for accessibility right from the start. Use these 12 steps as a guide when designing your website to avoid any accessibility issues.

Continue reading “How to Design for Accessibility When Building A New Website” →

By Sam Stemler on Oct 9, 2018

Throughout the U.S. and throughout the world, the number of laws requiring equal web and electronic accessibility for all are growing. In the U.S., Section 508 of the Rehabilitation Act is at the forefront. While it does not apply to privately owned websites, such as individuals’ or private businesses’, it does require accessibility for all federal websites and electronic materials. Section 508 was updated in January 2017 to take new technologies into account, and to improve enforcement. Federal agencies and groups had a year to comply with the update, and should now be in compliance. We’ve compiled the highlights and details of the Section 508 update to give you everything you need to know about Section 508 compliance for websites.

Everything You Need to Know About Section 508 Compliance for Websites

What does Section 508 Require?

Section 508 is intended to make electronic government resources available to people with disabilities. It was originally added to the Rehabilitation Act in 1998, and then updated in 2017. Section 508 includes electronic government resources needed or requested by the public as well as employees, so it affects internal and public-facing federal websites and resources equally.

Section 508 explains and defines key areas that must be accessible. The following subsections are quoted or paraphrased from Section 508 of the Rehabilitation Act Appendix A to Part 1194.

• Communications: This includes a wide range of messages, forms, surveys, announcements, notices of benefits, web pages, training materials and more that communicate information to an employee or user.
• Hardware: “A tangible device, equipment, or physical component of [information communication technology] ICT, such as telephones, computers, multifunction copy machines, and keyboards.”
• Software: “Programs, procedures, rules, and related data and documentation that direct the use and operation of ICT and instruct it to perform a given task or function. Software includes, but is not limited to, applications, non-Web software, and platform software.”

Generally, the bar for accessibility compliance in Section 508 is measured against the Web Content Accessibility Guidelines 2.0 AA (WCAG 2.0 AA) developed by the World Wide Web Consortium (W3C). WCAG 2.0 AA provides direction for many accessibility rules worldwide.

What Does Section 508 Compliance Look Like for Websites?

The new Section 508 update measures compliance against WCAG 2.0 AA, the same standard used in most of the world. Like Section 508, WCAG 2.0 AA does not give specific tasks that webmasters must fulfill to make a website compliant and accessible. Instead, the rules outline what accessible websites should do, with a focus on functionality instead of form. This gives webmasters the power to implement a solution works best for their needs.

The following are some of the most common website accessibility obstacles and concerns addressed in WCAG 2.0 AA:

• Design: The design of your website is essential to accessibility. Your design decides how pages are organized, your color scheme, navigation buttons and much more. Starting with an accessible design can make Section 508 compliance much easier.
• Navigation: To be accessible, your website should be navigable with a keyboard, as many assistive devices work similarly to a keyboard. For example, your navigation menu should be activated on click instead or (or in addition t0) hover.  It’s also helpful to have multiple navigation options for large websites, such as a site map or search bar.
• Text: Text should be relatively large and clear. Users with sight challenges should be able to magnify the text without altering the functionality of the site or the meaning of the content.
• Pictures: Pictures should not contain essential information, unless the information is also conveyed through alt text. This is particularly important for charts and graphs or buttons.
• Video: Videos should contain accurate subtitles.

Who Does Section 508 Apply to?

Section 508 applies to ICT of all federal agencies and the federal contractors who produce it. While it does not cover states or state governments, many states have adopted accessibility guidelines modeled after Section 508.

Though Section 508 provides specific rules governing ICT used by federal agencies, Section 504 extends the Rehabilitation Act to ensure equal access to any federal assistance. This includes any group which receives federal funding, such as many schools, libraries, and airports, among others. Section 504 does not make specific mention of ICT, but instead requires governing departments to enforce accessibility internally. For example, the U.S. Department of Education is in charge of administering Section 504 in schools. The accessibility of ICT through groups which receive federal funding and fall under the purview of Section 504 will be decided by the governing department, most likely with guidelines similar to Section 508.

Are There Exceptions?

There are some exceptions to Section 508. National security systems are explicitly exempt from Section 508. Some equipment used only for maintenance, repair, or monitoring are also explicitly exempt from Section 508.

What About Systems and Content Before the Update?

All systems and content that was in compliance with the original Section 508 standards before the 2018 update will still be acceptable under the “safe harbor” clause. ICT in compliance before January 18, 2018, when the update went into effect, will still be acceptable. However, any ICT updated after this time must be in compliance with the new rule.

Who Enforces Section 508?

The 2018 update to Section 508 imposes more specific accessibility rules for federal contractors. As federal contractors must adhere to the Federal Acquisition Regulation (FAR), the enforcement and regulation through contracts will be administered through FAR.

The Architectural and Transportation Barriers Compliance Board (AKA the Access Board) is responsible for researching and developing Section 508 guidelines. The Access Board is also responsible for future reviews and updates to account for changes in technology.

The U.S. General Services Administration (GSA) Office of Government-wide Policy will provide assistance to federal agencies creating or updating content or systems, and developing procurement guidelines.

The recent update to Section 508 focusing on functionality and foundational support through WCAG 2.0 AA brings web accessibility forward in the United States. Federal agencies provide a model for web accessibility compliance, and Section 508 provides a framework for equal access. Just as Section 504 of the Rehabilitation Act forged a path for the Americans with Disabilities Act to require equal access to private business, Section 508 may eventually become a compliance model for web accessibility for private enterprise as well.

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.