Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The definition of "parsed unambiguously" is rather ambiguous, and the gudelines themselves don't explain what is required. Does this mean a particular UA must have the same structure on each parsing of the same page (which only requires that UA behave deterministically) or that *all* UAs get the same structure (which is impossible without having all UAs store their data in the same way)?
For accessibility, it is vital that data be presented in a manner that complies with a published standard - otherwise how do UA-makers, or people who want/need to write their own parsing tools know what to expect and how to handle the data. With a multiplicity of UAs, the only sensible interpretation of "parsed unambiguously" is that the data stream complies with a published standard. That being the case, the guidelines should state this.
Proposed Change:
Simplify and strengthen the guidelines by removing the concept of "parsed unambiguously", and replace it with a guideline that says that data formats used must comply with a published specification (to be referenced in the baseline).
(Of course this may be an author-published one - though authors should be discouraged from doing so.)
To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:
Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quote are not complete.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.