Web Design Considerations Based on Users with Disabilities
The good starting point for web designers is to follow considerations based on different types of disabilities. For blind users, web designers should use semantic headings in their designs, (not just bold text). The ARIA landmarks are used to identify the layout of the page. For users who have cognitive disabilities, designers make sure that the content, and interface components like navigation menus are simplified and easy to understand. Provide alternative text for images that conveys their purpose.
This checklist is the highlight of some of the most important concepts for an accessible web design.
But try to do more research that how you can create designs that people with disabilities actually like, and how can they find it more useful according to their needs.
- Page Title
Does the page title (the browser title for the page; not the main content heading or <h1>) describe the topic of the page?
- Headings
Web designers should use semantic headings in their designs appropriately. Do not write text in bold or increase the font size where ever they want to highlight something.
Are the heading levels chosen so they convey their correct order in the content, not for their visual styling?
- Navigation
Web designers should provide 2 methods on the page where a visitor can go to “main content” easily.
Two of the main techniques web designers can apply,
HTML/ARIA landmarks (e.g. header, navigation, main, footer),
And “skip navigation” links.
- Links
Does link text clearly describe the purpose of the link?
- Magnification and Responsive Design
Can a low vision user magnify or zoom in on the content in the browser on any device, including desktop and mobile? Is the web design adjusted for all zoom states? Simplify the design as much as possible, eliminating horizontal scrolling.
- Touch Devices
Is the touch target size of main links and buttons large and far enough away from each other to activate easily with a finger? Is there another way to activate any custom swipe actions or gestures? Note that when a screen reader is activated on a touch device, it overrides all custom swipe actions and gestures.
- Color/Contrast
Web designers should not convey information with the color alone. They should use color and text both to indicate that a form field has an error. Is link text different from non-link text by more than just color?
- Images
Web designers should provide same informative text for informative images. The alternative text for actionable images, such as an image link, button, or image map area, clearly identify the link destination or button purpose. Complex images should fully explain in the page content and with a short alternative text description. Decorative images identified by the designers, as its not required alternative text. Is plain text used instead of text embedded in images? (Exceptions like text in logos and decorative text images exist)
- Tables
If the designers have a data table in the page content, then the table has a caption (name/title), and columns and/or rows properly identified in the markup.
- Forms
Web designers should have all form fields label visible. All form labels appropriately descriptive and instructive. Is all the information the user needs to fill out the form available on the page? Are all form labels and instructions next to their form element so that users (including users of screen magnification) can easily connect the form element with its label and/or instructions? Is Edit and Delete buttons next to the content they modify? Do error messages provide enough information for users to correct their error?
- Dynamic Content
Does the new content come right after the element in the logical reading order / tab order of the page?
Do all keyboard-only and touch screen interactions follow expected patterns so users know how to interact with all widgets on the page? When users activate scripted functionality (buttons, form submissions, etc.), they must know whether the action was successful or not, through a success/error message, the obvious activation of a feature (e.g. a video starts to play after the user activates the “play” button), etc. The feedback must be available to sighted users, screen reader users, and all other user categories.
- Custom Widgets
Does the design use standard HTML widgets (links, buttons, form elements, controls, etc.) whenever possible? Native widgets have built-in accessibility capabilities. Custom widgets do not.
If you do have any custom widgets, have they been created with full keyboard support, and are they compliant with WAI-ARIA authoring practices?
