Drupal and Accessibility: Does the Community Stand by What it Preaches?

Posted by Akshita Rawat on May 16, 2019 3:32:00 PM

“..an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.”

Calling accessibility as one of Drupal's core values and principles, the Drupal community has always stood to comply with web accessibility standards. Although with an absence of hard and fast rules to adhere to, the community has faced backlash in recent times.

First, with adopting Gutenberg (editor) and second with the release of Layout Builder, there have been some important questions and concerns about accessibility in the community.

This Global Accessibility Awareness Day, an awareness day to focus on digital access and inclusion for the more than one billion people with disabilities and impairments, let's take a look at how close is Drupal to its commitment towards web accessibility.

The Accessibility Controversy

a black and white design with G written in centreIn 2018, with WordPress 5.0 prepared to be released, the Gutenberg editor, a decoupled React based editing experience, was out for testing. Among other concerns like inconsistent user interface behaviour, difficulties with keyboard navigation through blocks ( far too heavily reliant on hover-based functionality), complexity to use it, the assessors were quick to call it inaccessible.

Drupal’s adoption of Gutenberg, got it in the fallout.

In another instance, when Drupal 8.5 released Layout Builder, the lack of accessibility in the feature brought the community into the topic of debate - how strongly does Drupal commit to accessibility?

How does Drupal ensure Web Accessibility?

Accessibility is about promoting inclusion than benefitting a small set of people with disabilities. It is about ensuring equal and inclusive access to the web resources, for the widest possible audience, without any bias.

And this has been reiterated in the Web Content Accessibility Guidelines (WCAG), that explains how web content can be made more accessible to people.

Drupal, in its Values and Principles, effectively lays down their commitment towards creating software which conforms to the accessibility guidelines. It conforms to the World Wide Web Consortium (W3C) guidelines which address:

  • Authoring tools, as part of the Authoring Tool Accessibility Guidelines (ATAG 2.0)
  • Web content, as part of the Web Content Accessibility Guidelines (WCAG 2.0)

As a result, it can be used both by developers as well as the site visitors.

Drupal has its own accessibility team, which helps identify the barriers occurring at the code level and the awareness level, and also resolves them. A number of such issues in the core have been identified and resolved, while also creating awareness within the community.

Some of these improvements included: Search engine form and presentation, drag and drop, color contrast, image handling, form labelling and so on.

Accessibility for developers is another added feature in Drupal, and through D7AX, it is an easy job to find contributed modules and themes which also support the development of accessible websites.

Let’s take a deeper dive into the key modules and features of Drupal that help overcome web compatibility issues, and ensure easier web accessibility:

Key Modules

Automatic Alt text It automatically generates an alternative text for images when no alt text has been provided by the user.
 Block ARIA Landmark Roles  It adds additional elements to the block configuration forms that allow users to assign an ARIA landmark role to a block.
 CKEditor Abbreviation  It adds a button to CKEditor which helps in inserting and editing abbreviations in a given text.
 CKEditor Accessibility Checker  It enables the Accessibility Checker plugin in your WYSIWYG editor, which then helps inspect the content accessibility level; and solve them.
 High Contrast  It allows the user to quickly switch between the active theme and a high contrast version of it.
 htmLawed  It utilizes the htmLawed PHP library to limit and filter HTML for consistency with site administrator policy and standards and for security.
 Style Switcher  Themers can provide a theme with alternate stylesheets. Allowing special styling for some part of the site, the module presents all those styles as a block with links. So any site user is able to choose the style of the site he/she prefers.
 Text Resize  It provides the end-users with a block for changing the font size of text on your Drupal site.
 Accessibility  It gives a list of available Accessibility tests, aligned to guidelines like WCAG 2.0 or Section 508.


Key Features:

  1. Semantics in the Core

Drupal has been built to encourage and support the proper use of semantic markup. Thus composing semantically correct HTML informs the browser and the assistive technology about the type of content it is managing with, and how this relates to other content.

This helps the assistive technologies carry out its activity effortlessly since they now have a structure to work with.

 2. Aural Alerts

Drupal provides a method called “Drupal.announce()” which helps make page updates obvious, in a non-visual manner. This method creates an aria-live element on the page.

 3. Controlled Tab Order

Drupal’s TabbingManager is an awesome medium to direct both non-visual and non-mouse users on the page, to access the prime elements in a logical order. And thus permits more control while exploring complex UIs.

 4. Accessible Inline Form Errors

Drupal forms are now more open to the expansion of available inline form errors. So now, it is easier for everyone to identify what errors made while filling in a web form.

 5. Fieldsets

Fieldset labels are utilized as systems for gathering related segments of forms. When effectively implemented, these labels give visual diagrams around the shape field gathering.

Presently, Drupal uses fieldsets for radios & checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal.

What was the Outcome of the Controversy?

As always, the community has stood by accessibility as one of the core tenets. In a blog, Drupal's commitment to accessibility, Dries Buytaert - Drupal Founder - writes on the issue and how seriously the community takes the commitment to accessibility.

With that said, he announced that the Layout Builder functionality would be in a "stable" state for production use after ensuring that it passes the accessibility gate (Level AA conformance with WCAG and ATAG). This holds for both the authoring tool itself, as well as the markup that it generates.

With accessibility maintaining team, it has been jointly agreed that:

  • The first priority is WCAG 2.0 AA conformance. This means that in order to be released as a stable system, the Layout Builder must reach Level AA conformance with WCAG. Without WCAG 2.0 AA conformance, a stable version of Layout Builder won’t be released. This happened with a stable release of Layout Builder in 8.7.
  • The next priority is WCAG 2.1 AA conformance. Because these guidelines are still new (formally approved in June 2018), the stable version of Layout Builder won’t be held on them but are committed to implementing them as quickly as possible, even if some of the items are after the initial release.
  • While WCAG AAA conformance is not something currently being pursued, there are aspects of AAA that we are discussing adopting in the future. For example, the new 2.1 AAA "Animations from Interactions", which can be framed as an achievable design constraint: anywhere an animation is used, it will be ensured that the designs are understandable/operable for those who cannot or choose not to use animations.

The commitment to this ideal, by the leadership at Drupal and by the larger community, has remained steadfast despite challenges. The announcement and commitment to conform to AA level has reinstated the faith in the community towards its values.  

Ready to build digital experiences that are truly great for your customers - frictionless, accessible, and inclusive? Drop us a line, and our Drupal experts will be in touch.

Topics: Drupal, Accessibility

Automated Accessibility Testing with A11ym

Posted by Sparshi Dhiman on Jun 21, 2017 5:53:00 PM

The A11y Machine or a11ym (pronounced as ‘alym’) is an open-source automated accessibility tool for web applications which crawls and tests web pages against accessibility conformance standards to provide detailed reports.
 
A11ym validates the web pages against following accessibility standards:

Why Accessibility?

Accessibility is not just about helping disabled people. It’s about making the web more inclusive and enabling people around the globe with different abilities to access web content with greater ease. Accessible websites not only yield good SEO reports but also avoid potential lawsuits. Hence, making websites accessible is beneficial in every way.

Why A11ym?

One of our clients, a renowned insurance company in Australia, wanted to perform accessibility checks on their current site. Imagine the amount of manual effort in terms of time, resources, and money required to perform the accessibility run for a complete website! To overcome this challenge we decided to look for an appropriate automated tool, which brought us to a11ym. 
 
It had a couple of compelling features which sealed the deal for us -

  • Can run locally 
  • Can test private code 
  • Can test auth-required parts
  • Can crawl all web pages
  • Can test single URL as well as multiple URLs
  • Team can focus more on fixing the code rather than finding errors

A11ym Installation 

Pre-requisite:

  • Java ( to allow a11ym to validate web pages against the HTML5 recommendation)
  • Node Package Manager (NPM): Open terminal and run following command: $ npm install -g the-a11y-machine. A11ym will be installed in your machine in no time.

To ensure successful installation of a11ym, open terminal and run command: $a11ym

 
You will see options list for a11ym
image2_0

 
A11ym Usage: 

Let’s start with typing the base URLs of website

Hit command : $ ./a11ym http:/test.org/

All URLs accessible from http://test.org/ will be tested against the WCAG2AA (default accessibility standard defined in a11ym) standard. In order to reduce the number of URLs to test, --maximum-URLs option will be used.

For example: if the only URL needs to be tested use --maximum-URLs 1 or -m 1
 

Testing list of URLs

What if the client wants to perform accessibility check on business critical pages instead of crawling complete website? In order to achieve the same, multiple URLs can be provided in two ways -
 

  1. Compute several URLs by adding them to the command-line, like this: $ ./a11ym http://test.org/Ahttp://test.org/B http://test.org/C
  2. Read URLs from STDIN, as follows: $ cat URLs.lists | ./a11ym -

URLs.lists is the file containing a list of web pages. It can be of other extensions e.g. URLs.txt. When reading several URLs, the --maximum-depth option will be forced to 1 be the default.
 
Note the  -: It means “Read URLs from STDIN please”.
 
Standards (WCAG2A, WCAG2AA, WCAG2AAA) cannot be combined with each other, except HTML5 that can be combined with any other. 
 
So for instance, to run WCAG2AAA:
$ ./a11ym --standards WCAG2AAA http://test.org/
 
To run WCAG2AA along with HTML:
$ ./a11ym --standards WCAG2AA,HTML http://test.org/

How a11ym works?

Following are the intricacies of a11ym

  • The node-simple crawler tool is used to crawl a web application based on the given URLs
  • Two type of tests are performed on each URL.
  1. Accessibility: PhantomJS runs and HTML_CodeSniffer is injected in order to check the page conformance. This step is semi-automated by the help of pa11y, which is a very thin layer of code wrapping PhantomJS and HTML_CodeSniffer,
  2. HTML: The Nu Html Checker (v.Nu) is run on the URL to validate web page against HTML conformance.
  • Results from different tools are collected and produced

A11ym Reporting

“a11y_output” folder will be formed in the same directory from where the run was executed, once the test run is complete. 
To view complete report open a11ym_output/index.html residing in same folder.
 
Report of all URLs will look like this:
image1_0User can view detailed report of each URL separately by clicking on specific URL link.
image3_1

 
 A11ym report bifurcates all the issues in three categories i.e. error, warning, and notice. 
A CSS selector is provided with each reported issue to select and analyse the buggy element. In addition to it, description and a link to the W3C recommendation is also provided.
 For example:

  • Notice: This button element does not have a name available to an accessibility API. Valid names are: title attribute, element content
  • Code: H25,
  • Rule name: #WCAG2AA.Principle2.Guideline2_4.2_4_2.H25.2.
  • Selector: html>head>title
  • Code extract: <title>Career With Test - Scrum Mast...</title>

 
You can follow the GitHub link to download the a11ym project and explore it further.
 
If you work with QA and test automation, you can also explore our posts on Behat installation and mobile testing automation tools.

Topics: Accessibility, Framework and Libraries

Accessibility Part 1: Designing with empathy for better accessibility

Posted by Roshan Ravi on Jan 4, 2017 11:59:00 AM

Current State of Digital Accessibility

Let’s face it. Differently-abled people working in the Tech industry is a tiny minority. Not just tech-industry, but businesses in general, have always been averse to hiring differently abled people. In India, people with disabilities working in the Tech industry constitute just one percent. 

Digital properties are usually built for people with no disabilities. Most businesses perhaps don’t see any value in serving a tiny minority of differently abled people. Enhancing the user experience and adding features that are useful for a perfectly abled person would ensure more business to a company than spending more time and resources on complying  accessibility guidelines.

Businesses thrive on data.  Analytics plays a huge role in understanding users and their behaviors. But, when it comes to differently abled, even Google Analytics won't tell you if a person is using Assistive Technology (Screen Readers, Voiceovers etc.) to use the website.

With little to no participation from differently abled, it is just impossible to convince businesses to even consider that tiny minority when building websites and apps.

Empathy does matter

It's a cliché. But, that doesn't make it any less true.  Humans are innately empathetic. We have managed to build great assistive devices for people with disabilities. We have learned to build our buildings that can be accessed effortlessly by differently abled.  However, when it comes to websites and other digital products, we still haven't learned to use the same empathy.

Empathy is the capacity to understand or feel what another being (a human or non-human animal) is experiencing from within the other being's frame of reference, i.e., the capacity to place oneself in another's position.

Bring Empathy into Design Process

Creating accessible web design, by cultivating a culture of empathy in a team or a business, requires making tweaks to the design and development processes. It needs to start from the ideation stage and has to follow through till the end of the project and beyond to the support stage. 

User Research and UX Design

User Research is the most important process of the development cycle of any project. When building an accessible web design, it is also important to keep the end users who are differently abled in mind before designing the User Experience.

  • Create user personas with different types disabilities. (Color blindness, hearing impaired and other physical and cognitive disabilities)
  • If possible, have differently abled people in the UX Discovery workshops
  • If the above one is not an option (which usually is the case), give as much importance to the Differently Abled User Personas as you would to the normal set of User Personas.
  • Put yourself (and the attendees of your UX Discovery Workshops) in the shoes of Differently Abled user personas and create detailed User Journeys.
  • Identify commonalities and differences between the user behavior of Perfectly abled User Personas and Differently Abled User Personas. 
  • Design User Experiences for all types of users. If required, design different user experiences for users with different disabilities. For example, the user experience for a Visually Impaired will be vastly different from that of a person who has limited use of hands.
  • UI Design

 

Most UI Designers love subtlety.  While using subtle UI Elements with less color contrast and smaller fonts makes for a visual treat, it hampers the accessibility.  But, that doesn't mean that a designer has to compromise on the quality of design to conform to accessibility guidelines.  Great designs -- or any work that requires creativity -- have always been created when working with limitations and restrictions.

  • Make texts readable by using adequate contrast and size, selecting fonts that are easy to read.
  • Use Icons carefully.  Icons get misinterpreted if they are not communicating the message clearly.  When using icons, they also need to be familiar and standard so that it is easy for users to remember what it does.
  • Always test the designs by converting the mockups into Greyscale. This will help you understand how a color-blind person would see your designs.
  • Responsive Web is not a feature.  It's a standard.  When designing websites, always keep Portable Devices in mind.  Accessibility is not limited to just Differently Abled people using Computers.  All devices matter.
  • Learn about Section 508, AA, AAA standards and WAI and follow those standards when designing websites and apps.

Prototype, Test, and Validate

The best way to validate User Experience of a digital property is to create prototypes and test it with real users. When testing an accessible web design, a well-built prototype will help emulate the features of a website or app for all types of users including differently abled users. When testing with real users is not possible, use the User Personas identified during the UX Discovery and have developers and QAs use the apps by emulating their user behavior.

Note : A lot of Tech Companies build prototypes using tools like Axure or by converting mockups directly into Clickable Prototypes. While this saves time, it certainly won't help you in understanding the User Behavior.  Build prototypes using Front-end Technologies (HTML, CSS, and JavaScript). Prototypes should be able to replicate all the features of a digital property and should be as close to the final design as possible.

Accessible web design also requires the support of a technology framework that can build the desired featured. Here's a look at how Drupal 8 accessibility fares in this regard, and what's still to be achieved.

This is the first part of a series of articles on accessibility. I am writing the next part - Innovation in Accessibility - and will be updating this Article with links.

Topics: Accessibility

Inclusive design: An introduction to accessibility whys and hows

Posted by Nilanjana on Sep 24, 2015 3:55:00 PM

DrupalCon Barcelona was full of interesting sessions. Here is one on Inclusive Design by Radina Matic.

Why web accessibility is important?

The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and many more. It is essential that the Web is accessible in order to provide equal access and opportunity to people with disabilities. An accessible Web can help people with disabilities to participate more actively in society.

List of Web Accessibility-Related Litigation and Settlements

Test with users, a11y compliance does not always mean functional compliance

Best practices lead to a better experience for everyone, not just disabled users

How to implement accessibility

There are few things we have to take care when developing websites:

  • Pages and elements within pages should be navigated with keyboard
  • Marking up forms semantically
  • Adequate colour contrast
  • Use of ‘alt’, ‘title’, ‘em’,  and use ‘aria’ attributes

Topics: Accessibility

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us