Posted on behalf of the Drupal accessibility maintainers and written by Mike Gifford.
Drupal is well known for its accessibility. While not perfect, Drupal made an early commitment to accessibility when Drupal 7 was released at the beginning of 2011. Its release was delayed several months because the core team was working to include accessibility releases for both front-facing and back-end user interfaces. This was a huge step for a general purpose content publishing tool like Drupal. Our community was one of the first to make accessibility accommodations for people with disabilities as not just users, but also as authors.
At that time, Dries Buytaert, the founder of Drupal, announced that accessibility was going to be one of the core gates of accessibility. It is still rare to see a software project launch get delayed because of accessibility issues. In my experience, this demonstrates when a community really values accessibility.
So when Drupal was nominated for the 2022 GAAD Pledge (an initiative of the GAAD Foundation that works with one influential open source project annually), we knew we had already demonstrated commitment to this part of the pledge.
The GAAD Pledge committed projects to formally update their guidelines to WCAG 2.1. WCAG 2.0 is still the default for many organizations, and Drupal was no exception. WCAG 2.0 was released in 2008, 18 months after the first iPhones were available for sale. Members of the Drupal Accessibility Team started looking at how they would implement WCAG 2.1 AA before it was released. The Accessibility Team has embraced 2.1 informally for a long time. We could have left it there, but we knew WCAG 2.2 and WCAG 3.0 were being developed. As such we updated our commitment to follow the latest W3C WCAG Recommendation.
We do not have a formal adoption of the Accessibility Coding Standards, but we are close. The Drupal Standards team may want a few additional changes, but we have documented many of the best practices that we have built into Drupal. We looked at other Accessibility Coding Standards, and felt we were able to create a project specific accessibility standard that was going to be helpful in educating people who are new to either Drupal or Accessibility.
This was tied to the important step of cleaning up our documentation. The instructions built into most open source projects are out of date, or incomplete, yet they are so important. This is especially true for accessibility. People new to accessibility, need an entry point that allows them to access the information that is relevant to the latest versions of the project. We’ve worked to improve this for Drupal.
We have been tracking accessibility issues in Drupal Core and Contrib under the accessibility tag. This is already a long-standing practice, and we have a staggering 2817 open issues.
How can we be a leader in accessibility, and have so many open issues? Ultimately, it is really a factor of how complex the user interface is, and how actively people are addressing issues. We have an active developer community with lots of modules and themes.
We recently started tagging issues for WCAG Success Criteria. Going this extra distance helps aggregate issues. With Drupal Core we can better understand the impact of particular issues on populations we care about. It also helps us create an Accessibility Conformance Report (ACR). I’ve outlined the process that we put together for Drupal and ACRs.
We are hoping to be able to provide a machine-readable ACR into every release of Drupal Core in the form of a simple OpenACR file.
We’d love to have members of the Drupal community become involved in helping Drupal continue to lead on accessibility. Help us take the next steps to ensure that we are catching accessibility errors earlier. We also hope that everyone takes time to engage in Global Accessibility Awareness Day, where we can share best practices and learn from each other.
Break down barriers to communication with clear and concise writing
When it comes to web accessibility, a lot of attention gets paid to how to present and structure content. Text size, color contrast, and use of headers are all vital parts of accessibility. Just as important, however, is making sure that the content itself is written in an accessible way.
One of the best ways to do this is by adopting the use of plain language. Plain language is the art of writing clearly and concisely to communicate your message to your audience. It makes information and content easier to read and understand. It helps bridge communication gaps, simplify complex concepts, and promote clearer understanding.
You can find plain language everywhere in society. Medical and legal professionals, educators, and others use it to communicate complex ideas. Federal agencies are required to use plain writing when communicating with the public. Businesses use it to reduce errors and enhance customer service.
Plain language serves as a powerful tool for fostering inclusivity and accessibility. It can help address educational and social inequities. It makes information accessible to wider, more diverse audiences, including:
Nearly everyone benefits in some way from the use of plain language. It's a crucial tool for effective communication in virtually any field or context.
Last year, I worked with a group of Drupal community members to update the project’s code of conduct. As part of our process, we created draft language drawn from other open source codes of conduct. We then asked community members from around the world to review and share their feedback. The top piece of feedback we received was to make the language easier to read and understand.
The other codes of conduct we used to create our draft was written at a college graduate reading level. This made it hard to understand, especially for an international audience. Our goal was to simplify the text without losing its meaning and nuance.
Despite our best efforts, we were not able to remove every long word or complex sentence. However, we were able to make the text much clearer and more direct. As a result, community members should find the new code of conduct easier to understand and follow.
This experience helped me better understand and appreciate the value of plain language. I learned that it takes a lot of hard work to communicate complex ideas in an accessible way. That work is worth it though, if it helps make the Drupal community more inclusive for more people.
A good starting point for learning more about plain language is Plainlanguage.gov. The site offers resources to help federal agencies follow the Plain Writing Act of 2010.
Guides on how to use plain language to communicate health information can be found at:
The Center for Plain Language provides plain language resources, training, and advocacy.
While mastering plain language takes effort and practice, its benefits are considerable. It can help break down barriers, improve comprehension, and facilitate better decision-making.
I tend to scribble a lot by Nic McPhee, licensed under CC BY-SA 2.0.
Community Content Strategy Drupal Open SourceThe upgrade from Drupal 8/9 to Drupal 10 is considered to be one of the easiest major upgrades in Drupal's history. This is because Drupal 10 is built on the same codebase as Drupal 8/9 and focuses on removing deprecated code and dependencies.
E-commerce businesses need a robust platform to succeed in this competitive online marketplace. Selecting the perfect e-commerce platform for your business can be a tedious task amidst a sea of solution providers. This is where the likes of BigCommerce and Drupal Commerce come into play, as they offer unarguably the best choices for businesses of all sizes.
While both platforms provide comprehensive solutions for businesses of any size, which one is the perfect fit for you is still a question in many users' minds. By analyzing the characteristics and benefits of both platforms, this article will provide you with the necessary information to make informed decisions without any twinge of regret.
For the first time in over a decade, Centarro will not have a booth at DrupalCon North America. In this post I explain why and share how to find Drupal Commerce content at the event or to plan personal connections in Pittsburgh instead.
While I was eager to exhibit and had already paid, I rescinded my sponsorship after the event added a mask mandate in February. At this point, enforced masking provides dubious benefit to anyone while degrading the conference experience for everyone. It suppresses the value of exhibiting through reduced exhibit hall engagement, impacting all of our sponsors who pay tens of thousands of dollars and help make the event a success. It disrupts the main purpose of gathering together - socializing with and collaborating with our peers. I could not in good conscience ask my staff to exhibit in masks or to consent to the guidelines in advance but ignore them in person, as was the practical result of similar rules in last year's DrupalCons.
Read moreLast year at DrupalCon Portland 2022, Dries announced that "Drupal is for ambitious site builders." It refined the "Drupal is for ambitious digital experiences" vision. It chooses to focus on a specific persona and improve their experience with Drupal. It didn't sit perfectly well with me, so I wrote about how improving the Drupal developer experience empowers the Ambitious Site Builder. And with Drupal 10, there has been a huge shift in the development experience for frontend developers. Drupal 10.1.0 will bring even more improvements to the frontend developer experience. One of those will be the new Development Settings form to manage Twig development mode and markup caching.