September 10, 2023

A Practical Guide to Building Accessible Forms on the Web

Exygy is still incorporating lessons and insights from Figma’s Config Conference. Check out some of our key takeaways!

It has been three months since Config, Figma's annual conference, and the Exygy design team continues to incorporate the lessons and new features we learned about into our daily work.

For example, the introduction of “Variables” alone will change the way that we design. It will save hours of our team’s time and make for more robust designs and improved user experience.

With so much already covered about Config, I wanted to take a moment and reflect on one of the smaller sessions that happened at the conference. On opening day, Putting Accessibility at the Heart of Design and Code, a talk composed of two smaller talks covered themes that our teams at Exygy have been focusing on more in recent months:

  • Accessibility exists under the umbrella of Inclusive Design and can help connect efforts between design principles and product vision.
  • Web forms, which are at the center of most products, art critical when addressing accessibility needs.
  • Cross-functional collaboration is essential when delivering on accessibility.
  • Whenever possible, we need to be talking to and testing directly with people with disabilities

For insights from the other talk, check out our blog post - here.

Putting accessibility at the heart of design and code

A practical guide to building accessible forms on the web

Kateryna Porshnieva led a deep dive into the details of form accessibility and how product teams can level up the accessibility of their user experience. Our own team has realized that web forms are at the center of most interactions with the government. A form’s design can mean the difference between someone who does or doesn’t get the human benefits they need.

This speaker discussed the importance of inclusive design, specifically in digital products. The talk covered various barriers to access when delivering forms, including color contrast, focus, semantics, labeling, hints and instructions, ARIA, required fields, validation, and live regions.

Here are some key takeaways:

Color contrast

  • Despite being one of the most talked about accessibility concerns, color contrast is still the most common issue. In fact, 84 % of all web pages have some form of contrast error
  • While text contrast is usually addressed, fewer people address the need for contrast on UI elements like buttons and form fields
  • Kateryna pointed out that these updates don’t only help people with visual disabilities but also those with situational limitations similar to Microsoft's writing on Inclusive Design.

Focus state

  • Browsers by default provide a focus outline to indicate which element is currently operable by a keyboard.
  • Unfortunately, it is common for designers to either remove or replace it with something that lacks contrast because they don’t feel like this matches the aesthetics of the brand.
  • Instead of removing focus outlines, it is possible to replace them with custom, well-designed elements that still match the design language.


  • Assistive technology uses semantic markup to help navigate forms. HTML is where everything starts and is the basis for page structure.
  • Something that I didn’t know was, as well as building the web UI, browsers are also building an Accessibility Tree. This tree contains all the info about accessibility elements on the page.
  • This is why its important that we use the correct markup when coding a page so the screen reader can read it properly.
  • Shout out to Kateryna for dealing with some major technical issues during the talk. Much of their talk relied hearing the screen reader “read” what it found. When the tech team could not fix the issue she literally “read” out the markup herself in order to simulate the screen reader. The crowd applauded the perseverance. A highlight of the conference!


  • Imagine using a form with no labels on it. This is the experience for 36% of all forms on the web.
  • In the example she had used placeholder text instead of labels. This is problematic since usually it has less contrast and it also disappears as soon as someone starts typing in a field. So its harder for folks with cognitive disabilities to track changes on longer forms. Its also ignored by many screen readers.
  • Instead best practice is just to use a label above the input. There is already a semantic label element that can be used.

Hints and Instructions

  • For general form instructions its best to keep them above and outside the form element. You want to do this because screen readers when entering form mode will omit content that is not interactive.
  • If you want to add specific instructions to an individual field you’ll want to place that content underneath the field.


  • ARIA provides a web standard that adds additional roles, states and properties in addition to semantic markup.
  • In the previous example, you can use ARIA to connect the label to the input.

Required Fields

  • Most common way to mark required is to add a red asterisk to the label. This element is read by default but can be hidden using aria-hidden.
  • It maybe be better to markup optional fields over required fields in the UI which is less intimidating to your users.


  • How we communicate error to users can have a dramatic effect on the user experience.
  • While we do want to leverage color to indicate success or failure, since there are several conditions that effect how people see color its important to use some other visual indication as well like an icon.
  • In longer forms, its also helpful to display an error summary at the top of the form.

Live Regions

  • My mind was blown when I learned that the summary field should be marked as a live region so as changes are made to the live region receives those updates without shifting the focus on the page.
  • As errors are corrected on the page the are reflected in the error summary and read aloud without shifting the user experience.

A Final Challenge

At the end, Kateryna emphasized the importance of involving real users with disabilities in the testing process and making incremental updates to move towards inclusive design. Testing directly with real people is something that our team has prioritized and has led to several partnerships with organizations serving people with disabilities, most notably LightHouse for the Blind and Visually Impaired.

Most recently our team has started an internal working group on form design for government. One of our goals is to explore how we can create thoughtful and inclusive experiences across our business lines. We’re excited to announce more on this in the coming months.

Related Reading

What’s a Rich Text element?

H1 example

H3 example

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Jesse James
Director of Design

Want to work together?

We are always looking to get in touch with partners to help build healthy and resilient communities together
contact us