SC 4.1.1 Parsing
Ensure markup code follows defined specifications to guarantee consistent presentation by browsers and assistive technologies.
- Syntax Requirements: Elements must have complete start and end tags, be properly nested, contain no duplicate attributes, and utilize unique IDs.
- Rationale: Valid code allows browsers to build an accurate Document Object Model (DOM), ensuring that assistive technologies can reliably interpret and present the page content to users.
- Validation: Developers should utilize HTML validators and code quality scanning tools to identify and resolve parsing errors during development.
- Scope: Applies to content implemented using markup languages (e.g., Web, some software, mobile native); does not apply to non-markup formats like PDF or standard Office documents.
4.1.1 Parsing: 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 any IDs are unique, except where the specifications allow these features.
Note 1: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark, are not complete.
SC 4.1.1 Parsing supports the principle of **Robust **because coding with markup, such as HTML, must be written per specification, using good syntax, so that browsers can present it correctly to end-users. When browsers are unable to consistently and correctly present the code, assistive technologies (AT) may deliver unpredictable results to users. It is difficult to predict exactly what problems may occur due to poor code parsing. The behavior may vary depending upon the type of AT being used and/or the browser being employed.
HTML or other markup code must meet the syntax rules that apply to it. The World Wide Web Consortium (W3C) defines the syntax rules for HTML specifications. (http://www.w3.org/TR/html52/introduction.html#a-quick-introduction-to-html)
Note: Not all markup languages have explicit guidance for what makes “well-formed” code. Specific examples of good and poorly formed code/syntax are included in the Examples sections.
General principles for well-formed code include:
- Using beginning and end tags, e.g., an indication of where the body of the Web page begins
<body>and where it ends</body>. - Properly nested elements, e.g., the beginning tag for a numbered item
<ol>that also has bullets appears before the bulleted list<ul>. The bulleted list would end</ul>before the numbered list ends</ol>. Each bulleted list needs to be properly nested inside the appropriate numbered item. - Elements do not contain duplicate attributes, e.g., an image only has one
<alt=>tag so that screen readers do not need to decide which attribute is correct. - Any IDs are unique. HTML form elements utilize unique identifiers (ID) to allow them to be understood by AT. The IDs must be unique to prevent confusion, e.g., using the same tag to identify different images or form fields.
Problems specific to AT can arise with code that does not meet expected syntax rules. This happens because Web browsers read the HTML code and use it to build an internal model. For example, the Microsoft Edge Web browser reads HTML coding for a Web page and creates an internal model called the Document Object Model (DOM). The browser then puts the information on the screen utilizing the information in the DOM using various Microsoft Windows user interface options available, including the accessibility properties for that information.
DOM acts as an interface between the HTML code and the browser (or other interface).
Impact of Nonconformance with SC 4.1.1 Parsing
| Type of Disability | Description of Impact |
|---|---|
| 302.1 Without Vision | Users who are blind cannot use a mouse to interact with electronic content and typically use an assistive technology, such as a screen reader, to get audible or other alternative output for the information represented visually. To be able to navigate the content, understand its structure and relationships, and understand the meaning of content represented in graphics and images, the content must provide textual and programmatic cues in addition to the content presented purely visually. |
| 302.2 With Limited Vision | Users with limited vision may have widely different visual perception. Individuals with limited vision may or may not use assistive technologies. Therefore, in addition to textual and programmatic cues necessary for assistive technologies, ICT must also present content consistently and predictably. Users who view content with magnifiers may not pick up alerts, warnings, or other content if such content is presented outside of a consistent and predictable navigation pattern or if the content is not itself viewable at large magnification. Content that becomes distorted when magnified can also prevent some users with limited vision from being able to understand or interact with the content. |
| 302.7 With Limited Manipulation | Some users may not be able to perform actions that require fine motor control (clicking and dragging), path dependent gestures (pattern-based passcodes), or simultaneous actions (Ctrl + Alt + Del). Providing alternative means to perform the same actions, such as entering the size specifications in an input field to resize an object or allowing sequential key entries, can enable users with limited manipulation to interact with the same content. |
| 302.8 With Limited Reach and Strength | Some users may lack sufficient strength to perform actions such as squeezing, grasping, or depressing a hardware control. Some users, including those in wheelchairs or of shorter stature, may not be able to reach controls that are placed too high or too far away from where a user would access the device controls or interface. ICT designers and developers must consider a broad range of statures, strength and dexterity limitations, and the needs of wheelchair users in order to provide interfaces that are operable with limited reach and/or strength. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Some users require more time than average to process information while others may find complicated instructions difficult to follow. Furthermore, some ICT content can distract or overwhelm users, preventing them from being able to interact with or understand other ICT content. Designers and developers of ICT must consider a broad range of cognitive abilities in order to provide ICT that is simple and easy to use. |
Applicability of Success Criteria 4.1.1 Parsing
| Technology | Applicability of SC 4.1.1 Parsing |
|---|---|
| Web | If Web developers follow HTML specification when developing content, then they will meet the requirements for 4.1.1 Parsing. Web developers can use HTML validators to identify any parsing issues that arise from missing start or end tags, duplicate and or conflicting attributes, etc. |
| Software | Not all software applications use markup languages, and among those that do, not all of them use markup languages in such a way that they expose the markup up to assistive technologies. When they do, they must meet the requirement for 4.1.1 Parsing. As with HTML, numerous code validators and code quality scanning tools exist that can help developers ensure that they are coding according to specification. |
| Office documents | 4.1.1 Parsing DOES NOT APPLY to MS Office documents because they are not composed using markup languages. |
| PDF documents | 4.1.1 Parsing DOES NOT APPLY to PDF documents because they are not composed using markup languages. |
| Mobile Native | Not all mobile-native applications use markup languages, and among those that do, not all of them use markup languages in such a way that they expose the markup up to assistive technologies. When they do, they must meet the requirement for 4.1.1 Parsing. As with HTML, numerous code validators and code quality scanning tools exist that can help developers ensure that they are coding according to specification. |