Skip to main content
2026-03-23•4 min read•navable Team•
report a barrieraccessible feedback mechanismBFSGWCAG 2.1keyboard accessibilityfocus managementdigital accessibility

The Accessible "Report a Barrier" Button: Best Practices for Design and Implementation under the BFSG

A website needs an easy-to-find, accessible way for users to report barriers. That does not require a modal dialog: a dialog can be useful, but a dedicated form page or an embedded form can work just as well.

What the Feedback Channel Should Do

The key question is not which UI pattern you choose, but whether the reporting path is easy to reach, clearly labeled, and simple to use. Users should be able to find it quickly, operate it with a keyboard, and understand when their submission has been sent successfully.

The visible label should be specific, such as "Report a Barrier." If the trigger is icon-only, it also needs a clear accessible name, for example aria-label="Report a barrier", so assistive technology users understand its purpose immediately.

Dialog: Useful, But Optional

A dialog is a good fit when you want users to submit feedback without leaving the page they are currently using. But it is not mandatory, and a standalone page is often the more robust option because it avoids complex focus handling and gives you more room for guidance, explanations, and form logic.

If you do use a modal, keyboard behavior has to be solid. Focus should move into the dialog when it opens, Tab and Shift+Tab must stay within the dialog, and focus should return to the triggering control when the dialog closes.

Technical Requirements

The trigger should be built as a real interactive element – a <button> or a link when it truly navigates to another page. It needs to be reachable and operable by keyboard, and the focus state should be clearly visible.

Contrast is part of the baseline. WCAG 2.1 requires at least 4.5:1 contrast for normal text and 3:1 for large text. These values matter not only for button text, but also for labels, error messages, and other important text in the form.

When the form shows validation errors, they need to be clearly identifiable and not communicated by color alone. Forms also work better with real labels instead of placeholder-only patterns, because that improves clarity and usability.

Best Practices and Common Mistakes

A mailto: link is not automatically wrong. As a lightweight entry point, it can be enough if it is clearly labeled, reliably available, and backed by a defined internal process with ownership, response handling, and follow-up. It becomes weaker when teams need structured categorization, tracking, attachments, routing, or reporting; in those cases, a form is usually the better option.

Good practice means a short, clear reporting path with only a few required fields and understandable categories such as "contrast," "keyboard," "screen reader," or "form issue." If you use spam protection, it should remain accessible and should not create a new barrier for keyboard or screen reader users.

Quick Technical Checklist

  • Clear entry label, e.g. "Report a Barrier"
  • Trigger reachable and operable by keyboard
  • Visible focus state
  • Clear accessible name for icon-only triggers, e.g. aria-label="Report a barrier"
  • Text contrast of at least 4.5:1 for normal text
  • Real labels and understandable error messages in forms
  • Use a modal only if it is implemented correctly; otherwise prefer a dedicated form page
  • If using a modal: move focus in on open, keep focus inside, return focus on close
  • mailto: can work as a minimal solution if the process behind it is reliable
  • Use anti-spam measures only in an accessible form

Sources