Finally started testing Bricks properly today, and there are serious issues with accessibility that render it basically unusable right now:
- Skip link to a div doesn’t work
This is standard practice, you add a hidden link that can be read by screen readers and tabbed to by keyboard that skips the navigation and drops straight down to the main content container. In my test I gave the very first section the CSS ID “main”, so the skip link is site.tld/#main.
What should happen is that keyboard focus jumps down to that div.
What actually happens is… absolutely nothing.
- Dropdown menus are not trigged by tabbing if a menu link has sub-items
Keyboard navigation is super important for accessibility and users who use screen reading technology. For it to work properly, it has to be able to focus on items like dropdowns so that the user knows what’s going on with the navigation.
What should happen is the user tabs through menu items, gets to the menu item with a sub-menu (the link for that menu item should be focusable, and is), and then tabs again to hover on the dropdown icon. At this point the dropdown should trigger, or failing that (best of the bad options) they can hit enter to trigger the dropdown (this requires them to know that the down icon is actually a link to expand the sub-menu, so it should have some form of a title role). Then the user can tab through the dropdown items.
What actually happens is the user tabs to the item with the dropdown, making that parent link clickable, but then they tab again and they’re off that menu item. Giving them absolutely no indication that there are sub-items, and no way to access them.
- Dropdown navigation items are COMPLETELY SKIPPED if the parent does not contain a link.
A follow on from item 2, but even worse for both the site owner and user. If you tab across to a menu item with dropdowns (but no link on the parent item), it simply gets skipped. Everything within that dropdown is completely inaccessible to the user. If they’re visually impaired, they may never know there’s a dropdown there, and if they’re motor impaired, they may well be able to see that there’s something there, but they can’t access it by keyboard.
What should happen here is, just like in #2, the user tabs to the menu item expand icon, and the dropdown triggers, capturing tab focus, so they can then tab through that new dropdown.
- Tabbing through the main navigation on desktop hits the mobile menu afterwards - so the user has to tab through an invisible menu with the same links they just went through. Both incredibly confusing, and crazy frustrating.
Someone using keyboard navigation should NOT be able to hit the mobile menu using tab when the mobile menu is not active.
- If the user is on a smaller desktop and the mobile menu is active, triggering the menu creates several problems.
The first is that there’s nothing to tell them that they’re focused on the mobile menu trigger. This can be solved with custom CSS on the focus state, but should be there out of the box.
The second is that once they’ve triggered the menu, tabbing through the menu items to the end then removes keyboard focus from the nav menu and places it back on the page, so they go from being in the menu, to cycling through page content, with the menu still being active. It should retain keyboard focus and cycle through the nav menu items to the close toggle, back to the nav menu items etc.
The third issue is the same as the first, once the toggle is activated, without additional CSS, there’s no way to tell if you’re on the toggle button to close the menu. Escape should close the menu by default.
/
At this point I just stopped testing because it’s a complete fail across the board to here on accessibility. These are issues that need to be resolved ASAP, as having inaccessible websites can result in major legal costs depending on where the user is - same for someone developing sites for clients who may not know about accessibility. They’re at major risk of being sued because of this stuff.
Bricks is brilliant so far (for non-accessibility-requiring users), but it’s going to be a huge target painted on any site using it for accessibility lawsuits if this stuff isn’t fixed super super fast.
Like, literally, all an accessibility lawsuit chasing laywer has to do is find a site built with bricks, and they’ll be able to sue them immediately due to the out of the box inaccessibility. It’s genuinely not safe to use Bricks on production sites right now if you’re in a country to accessibility legislation.
