Sep 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!

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.
Semantics
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!
Labeling
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
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.
Validation
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
Inclusive Design in Action: How Design, Engineering, and Product Collaboration Can Enhance Website Accessibility For EveryoneWithout collaboration, individual efforts may overlook important aspects of accessibility and may not fully address the needs of people using our products.
Demystifying Inclusive Design: Learnings on Designing Equitable and Accessible ProductsInclusive design consists of accessibility and equity. Exygy designers share their learnings from creating a design practice that centers inclusivity.
Accessible Affordable Housing: A Bloom Housing Case StudyOur Lead Designer, Jesse James, presents for California's Department of Rehabilitation Virtual Vendor Fair Bloom Housing's journey to work together with local community partner to make that our product as accessible as possible.
Resources
Sep 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!

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.
Semantics
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!
Labeling
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
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.
Validation
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
Inclusive Design in Action: How Design, Engineering, and Product Collaboration Can Enhance Website Accessibility For EveryoneWithout collaboration, individual efforts may overlook important aspects of accessibility and may not fully address the needs of people using our products.
Demystifying Inclusive Design: Learnings on Designing Equitable and Accessible ProductsInclusive design consists of accessibility and equity. Exygy designers share their learnings from creating a design practice that centers inclusivity.
Accessible Affordable Housing: A Bloom Housing Case StudyOur Lead Designer, Jesse James, presents for California's Department of Rehabilitation Virtual Vendor Fair Bloom Housing's journey to work together with local community partner to make that our product as accessible as possible.
Resources
Sep 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!

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.
Semantics
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!
Labeling
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
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.
Validation
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
Inclusive Design in Action: How Design, Engineering, and Product Collaboration Can Enhance Website Accessibility For EveryoneWithout collaboration, individual efforts may overlook important aspects of accessibility and may not fully address the needs of people using our products.
Demystifying Inclusive Design: Learnings on Designing Equitable and Accessible ProductsInclusive design consists of accessibility and equity. Exygy designers share their learnings from creating a design practice that centers inclusivity.
Accessible Affordable Housing: A Bloom Housing Case StudyOur Lead Designer, Jesse James, presents for California's Department of Rehabilitation Virtual Vendor Fair Bloom Housing's journey to work together with local community partner to make that our product as accessible as possible.