Pippin Williamson wrote a thorough and balanced review of page builders for WordPress that I would encourage everyone to read, whether you’re an end user or developer. He touches on accessibility a bit, but I wanted to go a bit further down that road, and didn’t want to write a novel in his comments. And so, this post.

First, WordPress is not to blame for page builders

Page builders, (and also website builders), were a thing long before WordPress entered the scene. WordPress is just putting its own spin on this trend. I can’t deny that there’s a huge market for page builders, no matter how much I dislike them. And let me tell you, that dislike is strong. I believe page builders and website builders are a huge contributing factor to the mostly inaccessible web we have today. I also firmly believe that, if you are going to create websites, you have a responsibility to at least have a general grasp of how the web works, what HTML is for, ETC., before you start creating websites. Yes, I know that sounds very elitist. But if you buy a car, you either have to maintain it yourself, or pay someone to do it for you. That option exists for websites too, but if you’re not willing to pay someone to build your website for you, then it’s your responsibility to learn how websites are built, and to then build them properly.

OK, page builders are here to stay. Now what?

Having said all of the above, I’m well aware that this battle is lost. So the next best thing, (if we’re stuck with page builders), is to ensure that users can’t do things like use HTML and CSS incorrectly without trying. If we’re going to give non-tech people the ability to build websites, then it’s the job of developers, (especially the ones who make page builders), to ensure that they do things correctly by default.

Cascading Stupid Developer Tricks

At this point in time, none of this is happening. Page builders create some of the worst markup out there. Some of them allow users to go in and change the markup, but this then defeats the purpose of a page builder, and given what page builders promise, (do all the things to build a website with no code), I can’t believe anyone seriously expects that users are going to go “Hey, this is horrible markup, let me go in and fix this”. And so we end up with a web that is inaccessible by default, and not just because of the developers who build websites, but because of the users who use page builders to build websites. I’d be willing to bet that the latter group far outnumbers the former group.

If you can’t, or won’t, ensure that end-users deploy standards-compliant markup and proper CSS, then you have no business releasing a page builder. It’s that simple. To do so without making it extremely difficult to build non-standards-compliant websites is completely irresponsible. If we’re going to give people the ability to build websites without learning HTML and CSS, fine. But that means that the companies behind all these page builders need to ensure that their developers, and designers, know their stuff. That means being familiar with standards, including WCAG, because it’s not a nice-to-have, it’s part of the package. Web designers and web developers breaking the web is bad enough. Don’t encourage people who want to build websites and are not designers and developers to further break it. Those of us who build the web ought to have enough respect for it to at least try to make sure that the things we build function correctly, and provide user experiences that work for everyone. To do otherwise is unethical on top of irresponsible, and makes us look like amateurs instead of professionals.

IBM maintains one of the best accessibility checklists outside of the corpus of WCAG 2.0 and related documents. they’ve now updated it in anticipation of the upcoming Section 508 refresh, which is slated to happen by the end of this year. If IBM’s making huge changes to accommodate the promised upcoming refresh, that gives me a little more confidence that it will actually happen.

The IBM Web Accessibility Checklist is extremely thorough. It provides an extensive guide on using the list itself, as well as current WCAG 2.0 checks which are mapped to the upcoming 508 refresh. It also includes legacy requirements for the current version of Section 508. Yay backwards compatibility!

If you’re not comfortable with reading through WCAG 2.0 and its related documentation, a good checklist can be a great place to start. It doesn’t substitute for the guidelines themselves, (sorry, you’re going to have to bite the bullet and become familiar with them), but it can guide you through changes you may be making to your websites or web applications to ensure that the changes you make are also as inclusive as possible. A good checklist can also serve as a template if you’d like to create one for your own organization that specifically reflects your workflows and practices. If you need a guide to the basics of what should be part of any accessibility checklist you create, this post on the defensibility of accessibility checklists contains a high-evel view of what should be included.

This talk by Luis Garcia at this year’s Accessibility Camp NYC, gives a very quick crash course on some accessibility tools that web developers can use to help make the websites and web applications they’re building more accessible. The slides for Luis Garcia’s Accessibility Camp NYC talk are here, and I would encourage you to follow along with them while you’re watching the talk.

Criteria used when choosing accessibility tools

There are a few notable accessibility tools that are not discussed here. This talk focuses on tools that are free, (as in cost, not as in speech), easy to use, fairly robust, (they’ll give you actionable information on a fairly large set of possible issues), and that will allow you to do local analysis. This last criterion is crucial for developers, especially if you’re running a local development environment like Varying Vagrant Vagrants or Desktop Server.

Most of the tools discussed are not free software or open source. Very unfortunately, free software and open source haven’t eaten the accessibility world yet. Each tool has its strengths and weaknesses though, and you’ll get the most out of this talk if you pick a tool you like, and stick to using that tool, as opposed to switching back and forth between tools. It’s also helpful when testing WordPress sites that you make a note of the markup that any of these tools is flagging, as well as the CSS. Since WordPress renders pages and posts based on templates, you’ll get a lot of duplicate errors that can be fixed by modifying an underlying function, or, in the case of CSS, a particular class that targets a template tag or shortcode you’ve created.

If you haven’t incorporated an accessibility tool into your workflow yet, you should

Accessibility tools aren’t the be-all-end-all for making websites and web applications accessible. There’s still manual work that needs to be done by everybody involved in the project. But accessibility tools will help you get on the right path towards making the things you build accessible to everyone, and they will save you some time and headache down the road if you apply the information they give you while you’re working on a project, instead of going back in after everything’s shipped and trying to add the accessibility later. That’s when accessibility becomes time-consuming and in some cases, very expensive. So save yourself the extra headache and expense, and start using an accessibility tool to help you integrate accessibility into your workflow

There’s a very thought-provoking article over at Rosenfeld Media by Whitney Quesenbery¬†that I think can be applied to the WordPress space. It discusses the challenges of making accessibility easy, or what I like to refer to as “democratizing accessibility.” I would encourage anyone who’s making things with and for WordPress to read it. I think that WordPress, (both the community and the project), is well-positioned to democratize accessibility, at least for the web. I also believe it’s our responsibility to do so, and that we will get there as long as we keep going forward. Accessibility’s got a lot of momentum in this community, and though we’re not perfect, and we’re nowhere near the point where accessibility and easily creating accessible content is the default, we’re moving in the right direction. But we all, (not just the WordPress Accessibility Team), need to challenge ourselves to make it as easy as possible for not only developers and designers, but content managers as well, to make things accessible. I would even go so far as to say we need to be making it as hard as possible to create inaccessible things, whether it’s a designer or developer doing the creating, or the cat blogger. We still have a long way to go, and it’s going to be an uphill battle, but I believe we’ll eventually reach that point.

In which I potentially piss a bunch of people off, but oh well.

As I browsed through work Twitter this morning, I came across this.

In case you don’t want to read the entire thread, or the embed gives you fits, the gist is this:
UX conference: Hey, we’d like submissions from ladies of marginalized groups.
Very polite accessibility professional: I’d love to help you out, but am unable to complete your form with a screen reader. Here’s a free alternative platform you can use.
UX conference: So sorry, maybe next time.

When pressed, the UX con asserts that, since their link has been spread so far already, and since they’re volunteers, they can’t do anything about it for now.

You had to go there, didn’t you?

I am loath to call any small outfit that doesn’t get accessibility right lazy, because I know that resources can be tight and knowledge is often limited. But this is an example of pure laziness and unwillingness to make even the slightest change. Being volunteer-driven is no excuse. The overwhelming majority of WordPress contributors are volunteers, and yet we’re working on the accessibility of our platform. Our link has been spreading for the last thirteen years, and yet we’re working on the accessibility of our platform. The problem here isn’t lack of resources, or that this UX con’s organizing team is made up of volunteers. Hell, every single WordCamp’s organizers are volunteers, and yet we somehow manage to make sure that inclusion of the groups this con is asking for submissions from, plus people with disabilities, is part and parcel of every single one of our events.

This isn’t about resources, it’s about priorities. I will be the first one to yell at accessibility folks when I believe things are going crazy. But you don’t get to trumpet your inclusion creds while blatantly excluding people with disabilities. That signals that every other effort you’re making towards inclusion of marginalized groups is a hollow one, and only serves as a cover-your-ass mechanism. It’s not like anyone’s asking for the con’s entire CMS to be rewritten. All that’s being asked is that you create an accessible form so that you can get the submissions you so desperately desire. But if you’re not willing to make your form accessible, an effort which might take you an hour tops, assuming that this is a complex form, (which it’s probably not), you might as well just say that your conference is for the privileged only. At least if you did that, no one would waste their time trying to help you out.