Test with a screen reader to be sure this information is available to the screen reader. This provides insight into how the control will be used and, in the best cases, allows screen readers to walk users through the process of using the control. In other words, indicate what type of UI control it is (e.g. Test with a screen reader to be sure the name or label is available to the screen reader. Give each control a name or label much like the labels used for standard form controls, as described in Pearson Guideline 14.When creating a custom UI control or evaluating/fixing a custom UI control from a Library: These will work well in more assistive technologies than you’ll be able to test in, and users will be used to using them. When possible, use a pre-existing standard UI control. General Techniques Use standard controls, when they meet the need *Requires proper labeling, see Pearson Guideline 14 When we create custom UI components, we need to ensure that the same information is available and that the same interactions can take place. In addition, screen reader users can work through the screen reader to select an option. For example, in HTML if you place a set of radio buttons on the screen, screen reader users will hear what the control is, how many options there are, what the options are*, which option is currently selected and which option has focus. When you choose to include a standard user interface element in a piece of media, it comes with much more than is seen by the typical user. HTML form controls, Flash accessible components) for their intended purpose or, if no appropriate standard controls exist, create or repurpose controls so that screen readers present the role, name, current state (including changes in state) and available options. The Microsoft PowerPoint Accessibility Checker.Don't provide info only through text formatting Check your markup for accessibility errors: Main navigation
0 Comments
Leave a Reply. |