Known Drupal/WordPress Bugs
The issues listed on this page are known or discovered issues by WebTech, but come from the website systems we use. We do our best to improve digital accessibility and overall user experience by contributing fixes to Drupal and WordPress where we can.
That said, the following issues now require help from the Drupal and WordPress communities to move them forward and make the fixes live. For each issue, we provide a related ticket or bug report to track, as well as any workarounds to try in the meantime.
Drupal Core
Navigation menus have a bug where if a relative path is used for the link, it trips up Drupal's routing logic and produces a "website encountered an unexpected error."
- Bug status: Current as of 11/14/2024.
- Bug report: not yet found.
- Workarounds: When adding a menu item, use Drupal's entity reference to refer to other site pages, instead of statically typing the URL. Example: if linking to your About page in your site navigation, you should search for "About" in the URL field, and not put "/about."
Views module
- When using grouping in view displays, the grouping labels are hardcoded as
<h3>
headings. If the grouped content is the only content on the page, this can create issues with skipped heading levels, especially skips from<h1>
to<h3>
. This is an issue in the Drupal core page templates, and requires a new option to selecting heading levels.- Bug report and work so far: Drupal issue #1383696
- Workarounds: In view settings, the element used for grouping will need its field or label set to the more accurate heading level. This usually results in empty
<h3>
tags from the template being rendered on the page, which accessibility checkers may flag as an issue. However, the empty tags currently don't seem to be conveyed on the page or to assistive technology.
- In view displays, the table format doesn't support an option for row headers. This is a Drupal core issue requiring a new option for setting a field as the row header.
- Bug report and work so far: Drupal issue #2770835
- Workarounds: No view-based workarounds are known. If row headers are necessary for a table and can be adequately managed, the table should be built and maintained manually rather than views. Where possible, tables should also be built as simply as possible, and complex tables divided into simpler tables if needed.
- Views using exposed filters for search fields and selecting filter options may use AJAX if they don't want an entire page refresh. This can cause issues with focus management in screen readers, causing users to start at the top of the page after completing a search or filter.
- Bug report: Drupal issue #3380058
- Workarounds: No known workarounds to easily fix AJAX. Views using search/filter with AJAX should ensure there is a heading labeling the search results, so users easily find them after a search or filter. Consider designing the user flow so the results show in a new page (similar to the Google search flow).
CKEditor module
When building a table the Header row/column option won't set the necessary scope attribute, even when permitted by the editor. This is a bug in the default editor, CKEditor 5.
- Bug reports: CKEditor Github issue #3175, Drupal issue #342707
- Workarounds: Scope must be added manually to table column/header rows through HTML source mode in the editor. See examples in the accessibility guide Add header cells to tables.
WordPress
Accessibility issues with the WordPress system will get filed here.