WCAG20/Institutional Memory/SC 4.1.1

Institutional Memory input for SC 4.1.1

Syntax vs content model

Christophe (and others from the original working group) have posted numerous times — as have I - that WCAG 4.1.1 which reads

> "Success Criterion 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."

refers ONLY to syntax nesting - so that the content can be parsed. This is also evidenced by the name of the success criterion, the other clauses in it, and the Understanding WCAG 2.0.

The UNDERSTAND WCAG DOCUMENT reads (emphasis added)

Intent

The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. 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 accurately parsed into a data structure or that it will be rendered correctly by specialized user agents, including assistive technologies, unless the content is created according to the rules defined in the formal grammar for that technology. In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably. Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar.

NOTE The concept of "well formed" is close to what is required here. However, exact parsing requirements vary amongst markup languages, and most non XML-based languages do not explicitly define requirements for well formedness. Therefore, it was necessary to be more explicit in the success criterion in order to be generally applicable to markup languages. Because the term "well formed" is only defined in XML, and (because end tags are sometimes optional) valid HTML does not require well formed code, the term is not used in this success criterion.

With the exception of one success criterion ( 1.4.4: Resize Text <https://www.w3.org/WAI/WCAG21/Understanding/resize-text>, which specifically mentions that the effect specified by the success criterion must be achieved without relying on an assistive technology) authors can meet the success criteria with content that assumes use of an assistive technology (or access features in use agents) by the user, where such assistive technologies (or access features in user agents) exist and are available to the user.

The intent of 4.1.1 was ONLY to assure that content can be accurately interpreted and parsed — so that a data structure for it can be constructed.

Nesting headings in any order (as long as its start and end tags are properly nested for each heading ) will not prevent a data structure from being created, nor the content from being parsed. So this is not covered by this SC.

It is unfortunate that we did not at the time realize people would conflate nesting of headings with parsing and data structures or we would have explicitly added a note making it clear that parsing has to do with syntax not semantics. It was not seen at the time - but some people refer to the start and end tags as elements while others refer to the combination of start and end tag together as an element. Hence all the confusion. (Just bad wordsmithing on the part of the Working Group)

The topic of heading nesting did come up, and the group specifically decided not to require it, since it was not something that prevented understanding of or access to content in any significant way. Bad form, but done all the time. And not seen as a serious accessibility issue.

There was also pressure to put strictly conforming to the HTML spec into WCAG. This was also decided to not be an accessibility issue. But parsing was since, in those days, AT looked at the code and built its own data structures — which could break if the content could not be parsed. So we settled on only requiring the parsing part of the HTML spec to be followed. Hence the name of the SC and the limited scope of it.

Complete start / end tags

I believe the way to do this is to explain -- in the Understanding document -- that

"Complete start and end tags"  does not mean "matching start and end tags".  They key is always what is in the specification.  If a specification only requires one tag in some cases then one tag would constitute "complete start and end tags" for that feature.     The phrasing of the success criterion was chosen to differentiate situations where specifications require start and end tags, but they are often missing because browsers can repair and recover from missing tags, but unfortunately not all AT could.   The language in the success criterion was never intended, and should not be interpreted to mean, that WCAG requires start or end tags that are not required  by the specification."

gregg

On Feb 9, 2014, at 10:15 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:

I agree with James’s interpretation also. This language is not open for changes at this time but we can make sure that the understanding document helps make this clear. If you have any suggestions for increasing the clarity, please pass them on..

From: Steve Faulkner [1] Sent: Sunday, February 09, 2014 10:20 AM To: James Nurthen Cc: w3c-wai-gl@w3.org; HTMLWG WG; HTML Accessibility Task Force; Richard Schwerdtfeger Subject: Re: WCAG 2.0 4.1.1 Parsing (elements have complete start and end tags)

"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. "

thanks James, that makes sense. though the wording could be clearer, while I have always considered optional end tags to be OK others have interpreted wcag as requiring them.

--

Regards

SteveF HTML 5.1

On 9 February 2014 15:10, James Nurthen <james.nurthen@oracle.com> wrote: Steve, The complete text is "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. "

As you have stated, the html specification allows certain end tags to be optional and some have no end tags so there is no issue with 4.1.1 as the specification allows these features.

Regards, James

On Feb 9, 2014, at 5:58 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> criteria 4.1.1 [1] parsing, requires complete start and end tags for all elements. > > "In content implemented using markup languages, elements have complete start and end tags" > > in HTML end tags certain end tags are optional [2] and certain elements have no end tags (<img>, <input> etc.) How do we explain/reconcile this disparity? > > > > [1] http://www.w3.org/TR/WCAG20/#ensure-compat > > [2] http://www.w3.org/html/wg/drafts/html/master/syntax.html#syntax-tag-omission: > -- > > Regards > > SteveF > HTML 5.1