Criterion Blog Articles
ELearning Courses on Website Accessibility
If your company is looking to better understand web accessibility, consider our self-paced ELearning courses! Whether you need an introduction to WCAGguidelines as a content creator, designer or developer, or you are looking for in-depth technical training, we have the course for you!
Criterion’s online training offer every client cost-effective, convenient and customizable WCAGand Section 508 courses! Each course offers highly interactive content with real-world scenarios using simulators, screen grabs, and videos! Unlike most courses on the market, Criterion’s online training doesn’t merely provide a high-level overview of accessibility. Instead, our courses immerse trainees in the most technical aspects of WCAG and Section 508 testing and repair! In addition, every client will receive a weekly management report detailing each employee’s status in the completion of assigned courses. Remember, Criterion’s award-winning accessibility courses are bundled with every WCAG and Section 508 audit project!
Our catalogue of web accessibility courses ranges from introductory courses for management personnel to WCAG 2.0 testing and repair courses for application developers. We also offer several courses focused entirely Section 508 and WCAG testing and repair of PDF , Word, PowerPoint, and Excel documents.
Criterion’s 2018 web accessibility courses include:
- Introduction to Web Accessibility
- WCAG Testing & Repair Techniques
- JAWS17 Accessibility Testing Techniques
- Designing for Web Accessibility
- Mobile Accessibility Testing & Repair Techniques
- PDF Accessibility for Adobe Acrobat DC
- MS Word 2016 Accessibility Techniques
- MS PowerPoint 2016 Accessibility Techniques
Remember: Section 508 Refresh Takes Effect January 18, 2018!
In about two weeks, on January 18, 2018, accessibly compliance to Section 508 Refresh for U.S. companies and government will go into effect. Before giving an introduction to the changes, here is a quick recap of U.S. accessibility legislation, Section 508, and of international accessibility guidelines, WCAG, as it is important to know both of these before understanding the Section 508 Refresh.
In 1998, the U.S. Congress passed Section 508, an amendment to the Workforce Rehabilitation Act of 1973. Electronic and information technology must be accessible to people with disabilities according to Section 508, allowing them to perceive and utilize information quickly and easily. Federal agencies, along with private agencies that receive federal funding or have contracts with federal agencies must comply to Section 508.
In 1999, the Web Accessibility Initiative (WAI-ARIA) of the World Wide Web Consortium (W3C) published a series of guidelines that took center stage as the international standards for web accessibility. The first version of these guidelines was the WCAG 1.0 which focused heavily on techniques of accessibility. In 2008, the second version, WCAG 2.0, replaced the first with more detailed and updated guidelines, focusing more heavily on principles of accessibility. WCAG is based on four main accessibility principles: perceivable, operable, understandable, and robust.
Last year, on January 18, 2017, the U.S. Access Board published an update to Section 508, often called the 508 Refresh or the [ICT] Final Rule. The key changes that the 508 Refresh offers are:
New Regulatory Approach and Format: This changes the old approach of Section 508 to better incorporate issues that stem from multifunction devices (smartphones) which are now in widespread, universal use.
Broad Application of Web Content Accessibility Guidelines 2.0: International accessibility standards and the U.S. standards for accessibility have differed significantly. The Refresh allows for Section 508-covered ICT to virtually conform to WCAG 2.0 A and AA.
Harmonization with International Standards: In addition to conformance with WCAG, other standards—such as the European accessibility standard for ICT procurement—have been considered in the Final Rule so that there is no conflict between it and these other international standards.
Delineation of Covered Electronic “Content”: Content now incorporates “all forms of electronic information and data.” This will help create a consistent document accessibility standard across federal agencies, both public-facing documents and non-public facing.
Expanded Interoperability Requirements: The Final Rule offers specific information about “operating systems, software development toolkits, and software applications” interacting with assistive technology ensuring functionality is at its height.
Extended Compliance Date and Incorporation of Safe Harbor Provision for Section 508-Covered Legacy ICT: Essentially, this states that federal agencies have one year to comply to the Final Rule from when it was first published in January of 2017. This also states that unaltered legacy content (Section 508 ICT) does not need to be modified unless the content is updated or changed. If the content is updated it will be held to the Refresh standards. This provision applies “on an element-by-element basis.”
Due to the new federal guidelines for accessibility compliance, federal vendors should have their information technology retested and Section 508 compliance documentation updated for 2018. For more information about the Final Rule, visit the U.S. Access Board webpage on the on the refresh.
Making Documents Accessible
September 2017 – Criterion
Accessibility is not just for web-based information, though that is important. Document accessibility is important for businesses to consider when they create content through Word, PowerPoint, Excel, and PDF.
While the Web Content Accessibility Guidelines exist as the global standard for web accessibility, there is no universal standard for documents. The International Organization for Standardization is a non-governmental international organization based in Geneva, Switzerland, that provides specifications for products, services, and systems through international voluntary standards. ISO 14289 is the organization’s PDF standard for universal accessibility, most often called PDF/UA. It is considered a complement to WCAG.
Requirements of PDF/UA include tagging content correctly and in logical reading order, using correct headings and nesting them properly, announcing important actions to users, adhering to proper color contrast ratios, providing alternative text descriptions for meaningful images, allowing assistive technology to access content, and providing appropriate navigation through a variety of means.
While much of those same issues must be considered for Word, PowerPoint and Excel, Microsoft documents do not have universal accessibility standards. Government agencies will have their own list of requirements, and best practices usually guide organizations and agencies that do not have their own.
In Microsoft products, beyond similar requirements for PDF/UA, here are four important considerations. (Please note this is a sampling of accessibility issues, not comprehensive.)
- Text Boxes
- Accessibility Checkers
First of all, tables need to be used for brief pieces of comparative information. They should not be used for decoration, spacing, or column formatting. Tables should be created by using the Insert Table tool rather than the Draw Table option. This allows for screen readers to read the tables easily. Add a caption to your table and in the table properties, allow heading rows to repeat on new pages. Do not allow the rows to break across the pages.
Text boxes are most often not accessible to screen readers, even when you have created them through the tool bar. For this reason, stay away from text boxes. For those using PowerPoint, a screen reader cannot access any formatting that happens outside the created layouts. Therefore, a document creator must use the Slide Master feature to create the layouts necessary so that no text boxes are added in the normal view. For a more accurate picture of what the screen reader can see within a PowerPoint, go to the Outline View of your presentation. If you have added a text box with text in Normal View, you will see that its content is not listed in the Outline View.
Extra unnecessary spacing throughout your document will be difficult for a screen reader trying to access pertinent information. Remove any extra spaces including spaces created by the enter key. To create spacing for aesthetic purposes in Word, use the Line Spacing feature in the Paragraph section of the tool bar. For Excel documents, format the cell size in order to making spacing as desired.
Built-In Accessibility Checker
Microsoft products now include a built-in accessibility checker. At the end of each document creation, you should check your document using this checker. It will easily pick up issues such as images with no alternative text or headings that are nested incorrectly. However, please note that these are not comprehensive checkers. They will not pick up if you have used a text box or forgotten to fill out the file’s properties. Logical reading order and color contrast must be checked manually. You will not be aware of headings labeled incorrectly or improperly structured tables by using the automated accessibility checker. These serve almost similarly to an HTML validator scan for a website. While they can catch a small percentage of issues, it should not be relied on heavily for testing whether or not a document is accessible.
Criterion’s Document Services
For more information about document accessibility including courses and document remediation services we offer, contact us at (888) 508-3973 or visit our Document Accessibility page.
Assistive Technologies for Blindness
September 2017 – Criterion
According to the World Health Organization nearly 40 million people are blind, and about 246 million people have low vision. Definitions of blindness vary from organization to organization, and from region to region.
According to the National Federation of the Blind, people are considered blind if their “sight is bad enough — even with corrective lenses — that they must use alternative methods to engage in any activity that person with normal vision would do using their eyes.” In the physical world, this could look like using a cane, service dog, or reading braille signs. When it comes to using technology such as a computer or mobile phone, those alternative methods to engage in activities are called assistive technologies.
Blindness assistive technology inputs — which send data to — include standard and braille keyboards, speech input, and hand gestures. Outputs — which receive data from — include screen reader voice output, refreshable braille output, and haptic alerts.
What does this mean for companies who are working to make their website 508 compliant?
- Testing your site should be done with more than one assistive technology. Just like in the physical realm where one person who is blind may use a cane and another may use a guide dog, it is important to note that users who are blind are not homogeneous. In order to reach a broader clientele, your website should be tested by a spectrum of blind assistive technologies. This means that manual testing must be involved in the process. See our blog on manual testing vs. HTML validator testing.
- Testing should be done by users who are blind and by users who are not blind. There are bugs that will arise when a person who is blind is using the technology he/she depends on that may not seem so important to someone who does not depend on that technology. Additionally, there are unseen bugs that arise. Literally. For example, if there is a section on your website that a keyboard does not tab over to because it is not coded correctly, a tester who is blind may not even know they need to warn you of that area because they do not know it exists. Testing is more thorough when diversity is part of the process.
- Giving more control to the user on your site will help your potential clientele stay on your site longer. If users who are blind are not homogeneous, then some will prefer certain things while others don’t. This means the more control you give the user, the wider the audience you gain at your site. See our blog on Using POUR to Your Advantage for more about website control.
More than 3.4 million Americans are blind, according to the Centers for Disease Control. By considering assistive technologies for people who are blind, you are building a stronger bridge between your products and a larger clientele of customers. Diversifying your customer base take intentionality but reaps great rewards.
Using POUR to YOUR advantage
August 2017 – Criterion
The Web Content Accessibility Guidelines (WCAG) outline four major adjectives that should describe your web content. Those adjectives form the acronym POUR: perceivable, operable, understandable, and robust.
If you are not familiar with accessibility at all, understanding these adjectives and what changes they imply for your website may have you feeling overwhelmed. Take heart. For private companies with 15+ employees and federal contractors, it may feel like accessibility is a thorn in your side. However, there are benefits that come from making your website ADA compliant.
Let’s take a look at POUR.
One out of five Americans have a disability. A major reason to have your website perceivable is to be able to reach that clientele. When a person with a disability "enters" an online store, accessibility is critical. If things are not accessible, he/she will move on to a new website. Providing text alternatives for non-text content allows someone who has a visual disability to "perceive" an image in his/her mind even if it cannot be visually seen.
In addition to bringing in a new clientele, your current customers will appreciate the perceivable principle. Providing full descriptions of images, links to data tables and complex graphs, captions and video scripts for multimedia, proper color contrast between foreground and background are all ways in which you allow your website content to be more easily perceived by all users. Alternative text for images actually improves your search engine optimization ranking, and all of these guidelines will keep users on your site longer.
Some people with disabilities may utilize assistive technology—things like braille keyboards, haptic notifications, speech input, voice over, etc. People who do not have reliable muscle control in the hands will use adaptive keyboards. Others may use one-handed keyboards, mouth sticks, head wands, or single switch devices.
When a person who doesn’t use a mouse arrives at your website, your goal is to offer them the access they need to stay on your site. Without operable standards in place in your web design, one in five Americans may not even be able to enter your site.
Providing focus indicators, logical and understandable navigation patterns and tab order, allowing extension of time limits, giving the user control over stopping or adjusting moving content, applying descriptive headings and labels, and offering more than one way for users to locate a web page within a set of other web pages makes your site more humanly navigable both for users who only use keyboards and for the many users who get stressed and leave websites that aren’t easy to operate.
Imagine that you created a website full of information and graphics that were both perceivable and operable. You’ve added alt text to all your images, you have a focus that follows the right pattern, you added captions to your videos, etc. You then publish your site and you are confident you will gain a lot of customers because of it.
In the morning you wake up and look at your site. To your surprise, the whole thing is in French! You know that the mistake needs to be corrected immediately because the English-speaking audience you are hoping to attract are currently going to your competitors’ sites.
While this analogy does not discuss all the nuances of this issue, it does prompt a better understanding of why perceivable and operable are not the only factors in the international guidelines. Language and functionality are two important aspects necessary to focus on in order to have an understandable website. These include but are not limited to using language attributes, page titles, providing instructions when asking for user input, and providing help when errors are detected in the user’s input.
Content must be stoutly built to handle different assistive technologies both current and future, and different versions and types of web browsers and operating systems. This involves allowing users as much control as possible so they can access content in multiple browsers including older versions. Much of this is done by a web developer who understands how to tag, nest, and uniquely ID elements on the webpage as well as programming names, roles and values correctly.
Set disabilities aside for a moment.
Human beings do not all receive and retain information the same. Some people are visual learners, others are tactile/kinesthetic, or auditory.
Customers like to have control. There is a psychology behind this desire for control. In fact, according to a Forbe’s article, customers have control whether you want them to or not. They can and will post their feedback of your company on social media.
The more options you have for your content, the more likely your current and potential clientele will interact with the content on your site as they wish. This means that you, as a company, are giving them control from the moment they arrive on your site. The POUR principles of WCAG will help you keep your current customers and gain many more, including those with disabilities.
4 Ways Accessible Websites are like Accessible Roads
August 2017 – Criterion
Imagine you are going to drive to a store to buy some groceries. If you had two options for your commute, one being a nearly-direct path from your home to the store and another being a path that takes three times as long, often has traffic jams, and constantly has road blocks and detours, which road would you take?
As important as navigation is to our physical world, it is just as crucial to the electronic world. When there are roadblocks in navigating the physical world, we get out our GPS and take a different road.
Online consumers do the same.
Keep in mind that there are nearly 1 billion people worldwide who currently live with a disability. Think of your website as a road between potential customers and your product. The trick is to make the path between the two as smooth and direct as possible. If customers cannot navigate your road, they will detour to your competitor’s.
Here are four ways accessible websites are like accessible roads:
Titles & headings are like road signs. If a customer is on his way to your store, he needs to know what to expect and how to arrive. When you have web pages with titles that describe their purpose, you help the customer know what to expect and where to go. When headings and labels within your website pages are nested and described accurately, it’s as if the road to your product is open and clear of traffic jams.
This also helps with search engine optimization. Sites that are easily navigable turn into sites that people stay engaged with, and therefore sites that easily attract more customers.
- Content bypasses are like highways. Highways allow for people to travel quickly around or through an area without having to stop unnecessarily. The Web Content Accessibility Guidelines (WCAG) 2.4.1 discusses the need to provide bypasses around repeated content. This may be done by adding links to the top of a web page or by allowing a potential customer to jump over repetitive content.
- Turning on the focus is like turning on street lamps. Potential customers that rely on keyboard functionality need the focus indicator/outline (most often simply called ‘focus’) turned on. This means that as they are tabbing through a website, there is a box, underline, or other visual change that happens to each linked button they come across. Without the focus turned on, the keyboard user cannot view where the tab is moving. In many cases, the keyboard-reliant customer will not purchase from a site where the focus is turned off. Focus must travel sequentially and logically, which typically means from left to right and from top to bottom. Additionally, focus must adhere to the WCAG color contrast ratio (WCAG AA = color contrast ratio 4.5:1 for normal text).
- Location options are like a user-friendly GPS. Using a GPS on our cell phones is typical in today’s world, especially when we aren’t familiar with the roads we are traveling on or if we need to find a faster, more-convenient route. For those traveling around on your website, you want to make sure that your site’s built-in GPS is easy to use and up to date. According to WCAG 2.4.5 there should be more than one way to locate a web page within a set of pages. This should include two of the following: providing a table of contents, providing a site map, offering a search function, providing a list of links to other web pages, and linking to all pages on the site from the home page. This allows potential customers to control the content they engage in on your site. Giving them this freedom will keep them on your site and coming back for more.
The more universally user-friendly you make your website, the more traffic flow you will get turning more viewers into customers. While this is not meant to be a comprehensive list of things to do to make your website compliant to Section 508 and WCAG, we are hopeful this analogy provides a new way of thinking about accessibility. While accessibility is necessary for users with disabilities, it is also a more universal way of building the foundation of your website’s infrastructure. Just as in the physical world, better infrastructure leads to a better economy. Adhering to WCAG–the universal electronic building code–will bring more travelers to your road, and ultimately more conversions of travelers to faithful customers.
Limitations of HTML Validation Scans
April 2017 – Criterion
Many Section 508 and WCAG accessibility vendors, who make most of their revenues licensing automated website accessibility testing tools, have recently begun posting articles that claim their HTML validation tools are the answer to Section 508 and WCAG compliance testing. Although the sales pitch may sound promising, the results are not.
Any reputable website accessibility vendor understands the only way to validate compliance with Section 508 and WCAG guidelines is to conduct extensive manual accessibility testing utilizing experienced accessibility professionals and expert end-users with disabilities using a variety of assistive technologies.
Quality HTML validators have their place in every web developer’s toolbox, but they are certainly not the answer to website accessibility testing given that they capture about 20% of Section 508 / WCAG guideline failures
Criterion is retained every week by companies who had previously engaged other accessibility vendors that promised them Section 508 and WCAG compliance simply by using their automated testing tools. Because these tools failed to ensure Section 508 or WCAG compliance as promised, these companies now face issues that either threaten their federal contracts or have resulted in threats of litigation.
Let’s take a look at some of the more common sales pitches we hear from our new clients by other vendors regarding automated website accessibility testing tools and HTML validators:
|Automated testing is faster||
Automated testing is not faster when the results of the scan don’t ensure Section 508 and WCAG compliance.
Typically, it takes less than 10 business days for a team of Criterion’s accessibility testers to document all Section 508 and WCAG failures within a website.
Additionally, due to the extensive documentation created through our manual testing, the average duration from the start of a website accessibility initiative to Section 508 and WCAG certification is only four months.
|Automated testing is cheaper||
Automated testing tools are not cheaper than manual testing. Many vendors license their HTML validation tools for 2 to 3 times the cost of manually testing ALL pages within even the largest and most complicated dynamic websites.
The cost for Criterion to manually test ALL pages on a website utilizing several accessibility experts and end-users with disabilities generally costs 25% to 50% LESS than the cost of licensing the most robust automated testing tools that will merely skim accessibility failures and result in a website that is not compliant to WCAG and Section 508.
|Automated testing is 100% accurate||
Automated testing is only as good as the algorithms behind the scan. Unfortunately, many HTML validators report false positives and have major compatibility issues with certain browsers.
All “Free” HTML validators should be avoided. These are ineffective in gaining true accessibility.
|Automated testing exposes all Section 508 and WCAG violations on a page||Automated testing exposes less than 17% of relevant Section 508 and WCAG compliance issues.|
|Automated testing is all you need to make your site accessible to screen reader users||
Automated testing is just a small piece of any comprehensive website accessibility testing protocol. In fact automated testing typically misses key components of allowing screen reader users to fluently move through a website.
Successful website accessibility initiatives are dependent on:
Remember, if you need to know that your website is Section 508 and WCAG compliant, its common sense to have the website tested by people who actually have disabilities.
|Automated testing tools combined with project management features allow for easier tracking and remediation of Section 508 and WCAG failures||
Website accessibility is not something above and beyond good website development. It is good website development!
The majority of Criterion’s clients are major corporations who have already invested considerable money, resources and training in their existing IT project management systems.
There is no reason for corporations to purchase a separate project management system that only tracks website accessibility issues and repairs. To do so reinforces the inaccurate perception that accessibility is an extra step in day to day website project management, design, development and maintenance.
Automated testing simply dissects code to identify inconsistencies with W3C standards and this is not the same as accessibility testing. Most objects and content on a page require human evaluation and the application of reasoning skills as content is compared to the more complicated guidelines set forth under Section 508 and the WCAG. Remember, context is critically important when testing website content and there is simply no algorithm capable of performing this type of evaluation.
Simply put, automated testing tools and HTML validators do not replace the need for manual testing by accessibility professionals and expert end-users with disabilities.
Below is a partial list of WCAG and Section 508 accessibility guidelines that automated testing is incapable of resolving:
WCAG 1.1 Text Alternatives / Section 508 (a):
Automated testing cannot:
- Test if Alt Text is meaningful and properly describes the image to the user.
- Determine if images have alt text when they should not, such as images that are links or buttons.
WCAG 1.2 Time-based Media / Section 508 (b):
Automated testing cannot:
- Check embedded videos for captions and proper audio description tracks.
WCAG 1.3 Adaptable / Section 508 (c), (d), (g):
Automated testing cannot:
- Check for proper context, for example, if multiple “Select” buttons exist on a page of drug prescriptions, it cannot identify that the relationship information to the associated item it will select is proper.
- Screen reader users need information and relationships of page information that is visually available but not programmatically available.
- Identify meaningful sequencing of information on your pages.
WCAG 1.4 Distinguishable / Section 508 (c), (l):
Automated testing cannot:
- Determine proper color contrast of text that is part of an image.
- Determine sensory instruction description violations. “Select the green button” is a violation that the automated tools will not detect.
- Determine structural issues that exist when resizing text to 200%.
- Determine if the site is using color to indicate error data fields in your forms.
WCAG 2.1 Keyboard Accessible / Section 508 1194.21 (a):
Automated testing cannot:
- Verify that menus are expandable and accessible via the keyboard.
- Verify that proper tab order corresponds with visual elements for screen reader users who rely on keyboard accessible controls.
WCAG 2.2 Enough Time / Section 508 (p):
Automated testing cannot:
- Determine if the user is given an option to extend a login session where they have been idle.
- Determine if a carousel does not have a stop or pause control.
WCAG 2.3 Seizures / Section 508 (j):
Automated testing cannot:
- Determine if visual page content flashes above 30 Hz.
WCAG 2.4 Navigable / Section 508 (d), (i), (o):
Automated testing cannot:
- Determine if tab order does not follow visual reading order.
- Determine sufficient focus borders around focusable elements.
- Check for context, such as multiple landmarks with the same term that need additional labeling for screen reader user to distinguish them apart.
- Determine if a Skip Navigation link actually goes to the correct part of the page.
- Determine if something is performed upon focus that should not be triggered without the user selecting rather than only focusing on it.
WCAG 3.2 Predictable:
Automated testing cannot:
- Check for dynamic content on an On Input event, such as one that that is triggered by the user’s selection of a radio button which displays additional input fields in a form that the screen reader needs to hear about.
- Identify inconsistent navigation throughout your site.
WCAG 3.3 Input Assistance / Section 508 (n):
Automated testing cannot:
- Tell you if you have proper error messaging being announced by screen readers
- Determine if form error identification is performed
- Determine if proper labels or instructions are provided to the user to input form information, or inform the user of required fields.
WCAG 4.1 Compatible / Section 508 (n):
Automated testing cannot:
- Determine if a series of tabs should be coded with role=tab or other techniques to be properly announce their role, state and value.
- Determine if you have proper conventions used for controls, such as expand and collapse items that are not coded correctly to announce their role, state or value.