Inclusive Design Series: How to stop worrying and love accessible forms
summary
Workshop-sized set of practical rules condensed into an hour: prefer semantic HTML and native controls, style but don’t replace the browser focus ring, and keep keyboard order tied to source order; use ARIA only when HTML/CSS/JS can’t solve it and manage ARIA state like aria-live polite for cart updates. Demonstrations include a show-tab-focus bookmarklet, a custom-form-field CodePen fallback pattern, and an error-summary pattern that moves focus on submit; validation fires on blur not during typing. Guides and code samples are available.
AI-written summary · about
chapters (31)
- 0:00Intro
- 2:13What is Simply Accessible
- 4:37What is accessibility
- 5:29Web Content Accessibility Guidelines
- 9:28Semantic HTML
- 12:01Progressive Enhancement
- 13:38Solution
- 15:03Source order matters
- 19:40Visible focus indicator
- 19:57Be flexible
- 22:03Building blocks
- 27:15Form field labels
- 32:48Custom elements
- 35:05Aria
- 36:46Aria use cases
- 38:27Remediating things
- 40:40Code snippet
- 46:03Autocomplete
- 46:24Semantic Information
- 46:57Complex Scenario
- 47:20Field Sets Legends
- 49:04Code Sample
- 49:34Best Practice
- 50:20Heading Structure
- 51:52Form Validation
- 53:10Research
- 53:49Validation best practices
- 55:01Error messaging
- 56:37Free guides
- 57:37Error messages
- 59:31Not the table
related talks
52mConsidering Accessible HTML Forms, JavaScript & WAI-ARIA
01h 12mPractical Tips for Building More Accessible Front-Ends by Sara Soueidan
35mAccelerating accessibility in web
28mDeveloper's Guide to Accessibility Mechanics
45mA Web for Anyone, Anywhere, Anytime
50mStructuring Accessible Forms
53mDoing Responsive Right: Accessibility Lessons from the Field
52mInclusive design challenges with UI widgets