You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was recently exploring Vicky Teinaki's incredibly good example prototype of accessibility issues in forms (password: accessibility). My team, Home Office Forms (HOF), is very interested in good form-building practice, hence the line of enquiry.
It demonstrates how, even when using using a front-end framework with accessibility at its core, poorly modified and designed forms can cause accessibility issues.
Many of the examples are modified instances of GOV.UK design system components or patterns. But do we think there is merit in any of the following?
Introducing a new section that shows bad examples of these accessibility issues
Embedding these 'bad examples' within the existing accessibility guidance pages?
Linking out to the prototype (obviously this leaves the door open for the link to break if the prototype isn't maintained)
Interested to hear your thoughts. Worth noting that a lot of this guidance will be included in any team-specific guidance we develop in HOF.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all,
I was recently exploring Vicky Teinaki's incredibly good example prototype of accessibility issues in forms (password:
accessibility
). My team, Home Office Forms (HOF), is very interested in good form-building practice, hence the line of enquiry.It demonstrates how, even when using using a front-end framework with accessibility at its core, poorly modified and designed forms can cause accessibility issues.
Many of the examples are modified instances of GOV.UK design system components or patterns. But do we think there is merit in any of the following?
Introducing a new section that shows bad examples of these accessibility issues
Embedding these 'bad examples' within the existing accessibility guidance pages?
Linking out to the prototype (obviously this leaves the door open for the link to break if the prototype isn't maintained)
Interested to hear your thoughts. Worth noting that a lot of this guidance will be included in any team-specific guidance we develop in HOF.
Beta Was this translation helpful? Give feedback.
All reactions