Accessibility

This page is a work in progress and represents the best of our current understanding at the time it is being viewed. It is not an authoritative document and not prescriptive.

Jump to:

Themes
Feast Plugin
Your responsibility
Testing tools
Quick fix
Buttons vs. links
External links
Drop down menus
Primary navigation menu
Navigate by headings
Resources
"Accessibility Ready" themes

Themes

The themes were not designed for ADA compliance.

As an off-the-shelf theme designed in 2015 and updated throughout the years, this was never a concern. Much like pagespeed became a hot topic in 2019, accessibility has started receiving scrutiny in 2020.

While the theme updates are bringing us more in-line with ADA requirements, the specifics are too nuanced for a $75 theme. Among updates we've made are:

accessbility compliance updates to Foodie Pro version 4.4.0

ADA compliance requires custom development from an experienced ADA developer, plus training and guidance. At this time, ADA compatible theme development/customization costs $10,000+.

Part of this has to do with liability. We are not willing to take on responsibility and risk from lawsuits for $100.

For reference, here's the accessiBe service for automated compliance.

accessibe pricing plans - from $490/year to $3500/year

Update 2020/05/24: even accessiBe is not a complete solution (thanks Casey)

There are things that we can do on the theme and plugin side to get you closer (eg. the keyboard-based "navigation links"), but there are things that are entirely your responsibility.

Additional reading from Carolina on theme accessibility compliance.

Feast Plugin

The Feast Plugin is being developed with accessibility in mind, and does a much better job than the themes. For example, see: Modern Homepage vs. Theme Homepage and Rethinking the Homepage.

But the plugin does not offer an ADA compliance guarantee either.

At the moment, there's no easy-to-follow guide that we're aware of. For example, the WCAG 2.1 checklist is a technical document that reads like molasses and can only be implemented manually by throwing dozens of $100/hr developer man-hours at, after a $x000 dollar audit from an accessibility specialist.

This is not something that's reasonable to expect from a $75 off-the-shelf theme or $199/year plugin. We are working towards improving accessibility compliance as much as possible so that you have less work to do.

Among improvements we've made:

Significantly improved internal links by replacing the "Featured Posts widget" with the FSRI block to:
- remove redundant links
- properly use aria-role="decorative" and no alt text for decorative images
- removed incorrect use of article schema, incorrect use of heading tags
- added visual indicator of currently selected item when navigating by keyboard
- provided better guidelines for using the FSRI block
Replaced the mobile and accessibility-unfriendly recipe index with the Modern Recipe Index
- Removes the use of "Featured Posts widget" (outlined above)
- Removes any reference to use the date-based, or category-based drop down menu
Created the Modern Mobile Menu to remove questionable javascript, and create a mobile/accessibility-first menu that removes cumbersome drop down navigation menus

Your responsibility

Complying with accessibility guidelines remains 100% the site owners responsibility. You are in full control of the content you write, the headings you use, the links you use, the navigation you create, and more.

Common issues food bloggers encounter are:

font size too small
- this is especially problematic when using a custom imported Google Font
low contrast (eg. fancy colors that don't offer enough contrast)
- also: background colors that reduce the contrast with text
missing alt text on images
- see this alt text decision tree on how to write alt text
using incorrect anchor text on links
- do not use "read more" or "see all"
using heading tags incorrectly
using javascript-based plugins for navigation
- do not use plugins to organize/filter your content that rely on javascript, such as for the recipe index

See this quick accessibility self-audit tutorial from Andrew @ Nerdpress.net

Testing tools

You can check your site's accessibility compliance using the Wave tool by Webaim.

This tool evaluates compliance on a page-by-page basis - you'll want to check your homepage, categories and posts all separately.

Prioritize your efforts on:

the homepage
your top 10 posts
then work through your categories and the remainder of your posts

Quick fix

~~The userway.org javascript snippet adds a little icon to your site that allows users to customize some common accessibility issues - font size and contrast for example.~~

~~However, this does not automatically fix accessibility issues on your site.~~

We previously recommend overlay tools, but have now been made aware that these may actually be worse. Tools that fall under this include:

userway
accessibe
pojo / one-click accessibility

We recommend avoiding these.

There is no quick fix. Accessibility issues must be manually resolved at their root cause.

Buttons vs. links

The themes were originally built to display some links as buttons, however this may not be the best setup for accessibility.

This is something we'll look into, in greater details. See: buttons vs links.

External links

External links need to be clearly marked as such, so that the user is aware when they're leaving your site.

We recommend the WP External Links plugin to manage the visual and aria notifications for external links.

Drop down menus

The themes were initially designed to allow for drop down menus as part of the navigation menu. For both pagespeed and accessibility, we're no longer recommending or supporting submenus in the navigation.

For maximum accessibility compliance, navigation menus should be short and concise.

Rather than use drop down menus and overstuffing the navigation, you should create indexes to help readers (and Google) navigate down through your site through topical silos.

Navigate by headings

According to the WebAIM survey from 2019, almost 70% of screen reader users navigate a webpage primarily by headings:

breakdown of ways to navigate a page on screen readers: 68% headings, 15% "find", small slivers for links, landmarks/regions and region

This is why it's important to use proper headings in your content.

A further 15% simply use the "find" feature.

Resources

"Accessibility Ready" themes

Some themes promote themselves as "Accessibility Ready", more information can be found at this post in accessible wordpress themes. You can find the official accessibility ready theme guidelines here.

This is absolutely a step in the right direction, but only covers a very small fraction of what ADA compliance requires.

The accessibility-ready requirements are based on WCAG2, but it is important to be aware of the disclaimer that a theme alone cannot guarantee that your website will be compatible with WCAG2 or other guidelines. Your theme is only one part of your website. Your content must also be accessible.
WordPress accessible themes documentation

For example, this Axe 3.5 ruleset just for screen readers is huge, which is only a portion of what "Accessibility" means.

You can find a list of "accessibility ready" themes here, which demonstrates just how lacking this is - they're blank sites with no content or functionality:

Starting with an "accessibility ready" theme means having to pay a private developer $10,000 to then build out ADA-compliant functionality.

To the best of our understanding, "Accessibility Ready" gets you maybe 5% of the way towards ADA compliance, and as such, is not a standard worth worrying about.

What "accessible" means is an evolving standard, and as moving target, will change frequently over the foreseeable future.