Developers Unite: Navigating Accessibility in WordPress

Talk by Nick Goodrum / View Slides

Accessibility for website and app developers can feel like a lower priority item or difficult to account for. Many look for plugins or quick fixes to patch up the work after the fact or often do not know where to begin. However, better accounting for all of the nuances is a lot easier when a developer knows what the end user’s experience is like. Luckily, nowadays we have more voices than ever coming together in the accessibility space to help.

In this session, we will cover what kind of users may be impacted by the code we create and the common patterns that can benefit them. We will look into how we can test our work before it reaches a QA team or specialist. All the meanwhile, we will go over the current state of accessibility tools and options in the WordPress space. Let’s join together in navigating how to build and maintain accessible code for the WordPress sites you make.

Questions on “Developers Unite: Navigating Accessibility in WordPress

    1. For the 100+ “accessibility ready” themes out there, it’s hard to say “this one and no other” as the best option. The main thing is that there was due diligence by the accessibility team to vet the themes that you can choose from. So even with some variance in setup, they all have work put in place to help reach the end goals of accessibility. I would say pick one that best caters to your interests and aligns for your setup as a starting point.

  1. Q: Why don’t developers lock in ‘required’ accessibility items within repository themes and plugins. For example, requiring alt text on all image or video content added or color contrast, etc?

    1. It falls under the ideal versus reality aspect of site creation. Enforcing that the person that uploaded an image also needs to enter the alternative text may not fit the flow of content creation for an organization. A video might need to be uploaded in its original form and the alternatives, transcripts, etc. are being worked on and may not be ready yet. A color contrast limitation needs to account for instances where it might be large text and when it might be small text, so it is hard to calculate which should be allowed without a lot of other information of what is showing on the backgrounds or in the text. Also, many companies have set branding colors and so the reality is they are set on the colors and may not use a platform that prevents them from being able to use them. I do agree that the ideal would be great. At the least, a warning system may be an approach to consider for theme creators out there.

    1. axe-core and Pa11y have CLI approaches that can be implemented into build tools. Depending on the amount of change and complexity of the interfaces you could also create integration or end-to-end testing. However, end-to-end testing does take a fair amount of setup and since in the end you should have it tested by specialists, QA, etc. the time might not be as beneficial. Having some regression tests with unit tests can be helpful. However, again in the end, humans and manual testing need to be involved in the process regardless.

  2. Q: How would you rank the page builders in relation to a11y? Page builders always seem to be adding new features, but is one working faster or more diligently to make their product better in this area?

    1. I have not vetted every single builder out there so I cannot say which one is absolutely the best. Of the ones I have looked through, they all do seem to have problems. Also, just like Gutenberg and other tools, mistakes do leak in as well and need to be resolved. I would say, at least check for builders/tools that at note accessibility as a priority or a focus item. Awareness is a good start for these, because it means they will likely fix them. However, I have seen bugs and errors sit for a while. The same is true of bugs in Safari, Chrome, etc. so big or small, we generally have to work around them. Likely find one that has done some diligence and awareness, then from there be aware that you will have to fill in some of the potholes and determine workarounds.

    1. For developers as a whole, is to step outside of their mold and experience what it is like to go through sites with assistive technology. Beginning to understand the struggles and pain points that sites are providing, will help create another voice to the community as well as make one more code piece be that much more aware.

      For those that have likely been learning and growing to the point they feel like they can help out, blog about what you’ve seen or found. Post issues and file bugs for the tools you use. If you have time also put in contributions to the plugins if you know a fix for them.

    1. I know of many that got into accessibility because of close ones or themselves having disabilities that influenced their lives. Mine is a bit lackluster in story telling and it was more of a “it just hit me” type of experience. I would say likely living abroad started already shifting my view outside of myself as I experienced cultures outside of my own. The same started happening as I came across more of the impact and influences of code on accessibility. I used the tools and software of many and it opened me up to the experience beyond my own. I interacted and learned from people, watched and listened to many presenters and individuals on their experience (just like many presenters from these 24 hours of presentations). Of course there have been/are strong web accessibility voices out there, such as Léonie Watson, Steve Faulkner, Karl Groves, and many more that we all learn a lot from.

  3. ​Is there any globally accepted rating system for accessibility that a developer can reference when reviewing a package or component across platforms – npm, github, WordPress?

  4. I would say WCAG is the guideline that is globally well recognized with many countries basing it as the core principles needed for websites, software, etc. Now as for a “rating system” to say one project is 80% compliant or 3/5 stars for accessibility, there isn’t one. Since code and pages are constantly changing, a stamp of approval could be lost with a recent patch or update. That’s why we as developer and site maintainers need to be the layer of due diligence and take ownership of the packages we include. Try and go through the GitHub issues to see if there are any or how many have been solved for accessibility, check for VPATs or accessibility statements, and test them out yourself if you can.

venenatis, ipsum Aenean Phasellus libero eleifend risus odio