Menu

7.5 Ready Reference for Developers

  1. It MUST be ensured that in content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and IDs , if any, are unique, except where the specifications allow these features. This helps to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed, then different user agents may present it differently. Some user agents use “repair techniques” to render poorly coded content. Since repair techniques vary among user agents, authors cannot assume that content will be rendered correctly by specialized user agents. (Ref. WCAG 4.1.1)
  2. Labels or instructions MUST be provided when content requires user input (for example in forms). Text instructions that describe the input must be provided at the beginning of a form or set of fields. Elements associated with input must be labeled to ensure that information about the input field is spoken by screen readers when the field receives focus.
  3. In situations where web functions are time-dependent, (for example, filling out online form) it will be difficult for people with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations to perform the required functions before a time limit occurs. This may render the service inaccessible to them. It must therefore be ensured that such users are given adequate time to interact with Web content whenever possible. For each time limit that is set by the content, the user MUST be allowed to turn off the time limit, adjust the default setting before encountering it or is warned before time expires and given option to extend the time limit with a simple action (for example, “press the spacebar”). (Ref. WCAG 2.2.1)

    Activities that essentially require a time limit (for example an online auction) or the time limit is too long (say 20 hours) are exceptions.
  4. Many users including the visually challenged cannot perceive shape, size or use information about location or orientation. For such users the content that relies on knowledge of the shape or position of objects becomes inaccessible (for example, “round button” or “button to the right”). Hence It MUST be ensured that instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. Additional information needs to be provided to clarify anything that is dependent on this kind of information. (Ref. WCAG 1.3.3)
  5. If an input error is automatically detected, the error MUST be described to the user in text. The error message should be as specific as possible. This will ensure that users are aware that an error has occurred and can determine what is wrong. Describing the error in text in addition to highlighting the errors will help screen reader users, who cannot distinguish colour and users with cognitive disorders who have difficulty in perceiving the meaning of other visual cues. (Ref. WCAG 3.3.1)
  6. All functionality of the content MUST be operable through a keyboard interface without requiring specific timings for individual keystrokes, except where input depends on the path of the user’s movement (for example, drawing freehand curves or using handwriting to write). (Ref. WCAG 2.1.1)
  7. Whenever a web page is rendered using plug-ins or embedded applications, it is possible that functionality of the Web page restricts the keyboard focus to a subsection of the content, unless the user knows how to leave that state and “untrap” the focus. This situation may affect navigation for people who rely on a keyboard or keyboard interface to use the Web, including visually challenged and people with physical disabilities. Therefore it MUST be ensured that if focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it is not possible the user is advised of the method for moving focus away. (Ref. WCAG 2.1.2)
  8. It MUST be ensured that the purpose of each link can be determined from the link text alone or from the link text along with its programmatically determined link context e.g. by using title attribute as a tooltip to clarify the purpose of link. (Ref. WCAG 2.4.4)
  9. When any component receives focus, it MUST not initiate a change of context. Developers must use “activate” rather than “focus” as a trigger for change of context. This ensures that functionality is predictable as visitors navigate their way through a webpage. (Examples of changing context when a component receives focus include forms being submitted automatically when a component receives focus or new windows launched when a component receives focus). (Ref. WCAG 3.2.1)
  10. Entering data or selecting a form control must have predictable effects. Changing the setting of any user interface component MUST not automatically cause a change of context unless the user has been advised of the behaviour before using the component. Unexpected changes of context can be disorienting for users with visual disabilities or cognitive limitations. (Ref. WCAG 3.2.2)
  11. Metadata adds semantic information to pages and sites and provides contextual information for people navigating the site, especially those with screen readers who rely on things such as page titles, structured page headings and lists. Metadata may also be used by some search engines. Indian Government websites MUST provide metadata like, keywords, and description at least on Homepage and all important entry pages.
  12. Tables help in organising and presenting data on a webpage. However, many designers in the past have been using tables to make the layout of Web pages. This has resulted in the Web pages not being accessible to people using assistive technologies such as screen readers. For this reason, Use of Tables for page layout should be avoided and for data tables, proper tags and markup MUST be provided to identify row and column headers and associate data cells and header cells.
  13. When users navigate sequentially through content, they should encounter information in an order that is consistent with the meaning of the content and can be operated from the keyboard. Hence if a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components MUST receive focus in an order that preserves meaning and operability. (Ref. WCAG 2.4.3)
  14. For all user interface components, it is a MUST that the name and role can be programmatically determined; states, properties, and values can be programmatically set; and notification of changes to these items is available to assistive technologies. (Ref. WCAG 4.1.2)
  15. Any keyboard operable user interface MUST have a mode of operation where the keyboard focus indicator is visible. This helps the user know which element among the multiple elements present in the page has focus. For e.g., in case of a button a visual change in the button (e.g. color, size) can indicate that the focus is on the button. (Ref. WCAG 2.4.7)
  16. If an input error is automatically detected and suggestions for correction are known, then the suggestions MUST be provided to the user, unless it would jeopardize the security or purpose of the content. Input error occurs if the user omits a certain information that is required by the webpage or the information provided by the user is not in the correct format or falls outside the permissible value.This is to ensure that the users receive appropriate suggestions for correction of input errors if possible. (Ref. WCAG 3.3.3)
  17. For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or submit user test responses, at least one of the following MUST be true: (Ref. WCAG 3.3.4)
  • Reversible: Submissions are reversible.
  • Checked: Data entered by the user is checked for input errors and the user is provided with an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.