Accessibility audit and fixes for site-wide issues

[mizmay]

A code review of #423 surfaced several accessibility issues, but there are likely to be more if we do a full audit. We should strive for WCAG 2.1 AA compliance, as this is the broadly accepted standard for what "accessible" means in practice, and because we do not want to exclude or frustrate those who rely on keyboard navigation, screen readers, or high-contrast displays.

Known issues (introduced with #423)

Keyboard inaccessible dropdown (WCAG 2.1 SC 2.1.1)

static/css/site.css

The dropdown is shown/hidden via :hover only. Keyboard users who tab to "Flings" can focus the trigger but the submenu never opens.

Fix: add :focus-within alongside :hover:

#menu li.dropdown:hover .dropdown-menu,                                                               
#menu li.dropdown:focus-within .dropdown-menu {
    display: block;
}

Hamburger button has no accessible label

_includes/nav.html

The #menu-expand button contains only a Font Awesome icon with no aria-label. Screen readers will announce it with no name. Should also toggle aria-expanded to reflect open/closed state.

Decorative icons missing aria-hidden

_includes/nav.html

Font Awesome icons used as decoration (e.g. the caret in the Flings trigger) are not marked aria-hidden="true". All decorative icons across the site should be audited.

Suggested Full Audit Scope

• All interactive elements have accessible names (buttons, links, inputs)
• Keyboard navigation works for all interactive components (dropdowns, toggles)
• Decorative images and icons have aria-hidden="true" or empty alt=""
• Focus styles are visible (not suppressed by outline: none)
• Color contrast meets WCAG AA minimums (4.5:1 body text, 3:1 large text)
• Page has a descriptive <title> and logical heading hierarchy

Resources

• WAVE Web Accessibility Evaluation Tool
• axe DevTools
• WCAG 2.1 Quick Reference