Re: Question #2 on 4.1.1 Parsing - what it covers - markup-wise

This is a quite good answer and agrees with my memory of the discussions as well
(formatting added below to aid in my reading) 

This was one of the most problematic SC - in that it was added in response to heavy pressure from reviewers - but is of a different character than all the rest of the SC.   For systems with good APIs, AT should not have to rely on reading the content markup directly - though that was done at time of writing.  

g


> On Jan 13, 2016, at 10:48 AM, Christophe Strobbe <strobbe@hdm-stuttgart.de> wrote:
> 
> Hi Katie,
> 
> SC 4.1.1 did not want to list specific markup languages such as HTML 4, XHTML, SVG etc. because that would make the SC technology dependent, and WCAG wanted to be applicable to technologies that did not yet exist at the time of writing.

> The SC did not want to single out XML-based languages because XML is not the only specification on which markup languages can be based.

> HTML 4 and its predecessors were based on SGML, where "well-formed" markup was not a concept. (SGML-based documents are valid or not valid when compared against the DTD.)

> HTML 5 went a different path; it neither has SGML-based nor XML-based schemas (XML DTDs cannot express all the conformance requirements of the HTML5 spec.

> HTML 5's HTML syntax is merely "inspired by SGML".) and does not have the concept of "well-formed markup". 

> ARIA is not a markup language but a "vocabulary" that you use in markup languages such as (X)HTML and SVG, so SC 4.1.1 does not apply to ARIA as such, but to markup languages in which ARIA can be used. 

> SC 4.1.1 applies to SVG, but I don't know to what extent SVG is accessbility-supported nowadays.

> 
> Best regards,
> 
> Christophe
> 
> PS: I don't think we discussed the relevance of this SC to technologies that use XML internally in the way that ODF (OpenDocument Format) and the MS Office XML formats use it. (I.e. all content, styling, metadata, etc. is internally represented as a set of XML files - except for binary image formats; these XML files are "zipped" so the format looks binary to non-technical users.) Office suites such as LibreOffice and MS Office have accessibility APIs that expose the document accessibility features to AT. I am not aware of AT that additionally also parse the office formats directly.
> 
> PS2: Some nitpicking: "Begging the question" does not mean the same thing as "raising a question". "Begging the question" is a logical fallacy: <http://skepdic.com/begging.html> <http://skepdic.com/begging.html> /  <https://en.wikipedia.org/wiki/Begging_the_question> <https://en.wikipedia.org/wiki/Begging_the_question>. 
> 
> On 13/01/2016 6:17, Katie Haritos-Shea GMAIL wrote:
>> Interesting, the predominant feeling is YES, just those 4 things. <>
>> This 4 things listed in 4.1.1 are:
>> 1.       elements have complete start and end tags, 
>> 
>> 2.       elements are nested according to their specifications, 
>> 
>> 3.       elements do not contain duplicate attributes, 
>> 
>> 4.       and any IDs are unique, 
>> 
>> except where the specifications allow these features.
>>  
>> Which begs the SECOND question:
>>  
>> Given the language of the SC:
>> 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. (Level A)
>> 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 quotation mark are not complete.
>>  
>> Do we as a Working Group believe that 4.1.1 is ONLY applicable to content implemented using HTML/XHTML/XML as the markup languages? (and if so, why didn’t we say that?)
>>  
>> Or, would this SC cover say, SVG or ARIA, or other languages or content that is used to implement and enhance markup languages, that may also contain start and end tags, elements, attributes, attribute values and/or IDs?
>>  
>> ​ ​​​​
>> (Yes, like many of you, I alsoo think about these things at midnight…….:-)
>>  
>>  
>> * katie *
>>  
>> Katie Haritos-Shea 
>> Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
>>  
>> Cell: 703-371-5545 | ryladog@gmail.com <mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545
>>  
>> From: David MacDonald [mailto:david100@sympatico.ca <mailto:david100@sympatico.ca>] 
>> Sent: Tuesday, January 12, 2016 2:20 PM
>> To: Katie Haritos-Shea GMAIL <ryladog@gmail.com> <mailto:ryladog@gmail.com>
>> Cc: WCAG <w3c-wai-gl@w3.org> <mailto:w3c-wai-gl@w3.org>
>> Subject: Re: Question on 4.1.1 Parsing - what it covers
>>  
>> This was a carefully negotiated and precarious issue in WCAG2. Some were very vocal and very strong about requiring full validation. In the end the consensus was that we did not want Accessibility Budgets being used up chasing down ampersands (&) and trivial things that browsers and AT have overcome. We wanted accessibility budgets to only be allocated to validation issues that impacted AT, and accessibility. This was the list we came up with. Some people like the folks at WebAim would like us to consider completely removing 4.1.1. 
>> 
>> I personally feel that we came up with a reasonable balance with the current requirements. Maybe in an WCAG.NEXT we'll review and give WebAim an ear to present their case, and also those who would like to see more validation requirements.
>> 
>> David & Kirsten MacDonald
>>  
>>  
>>  
>> On Tue, Jan 12, 2016 at 12:28 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com>> wrote:
>> Folks,
>>  
>> Do we as the Working Group consider 4.1.1 Parsing to include ONLY the 4 specific examples identified in the Success Criteria, or, do we believe that 4.1.1 Parsing to includes those 4 examples plus other things where parsing failures might affect AT?  (I know that a doctype declaration is NOT a parsing failure).
>>  
>> ​ ​​​​This 4 things listed in 4.1.1 are:
>> 1.       elements have complete start and end tags,
>> 
>> 2.       elements are nested according to their specifications, 
>> 
>> 3.       elements do not contain duplicate attributes, 
>> 
>> 4.       and any IDs are unique, 
>> 
>> except where the specifications allow these features.
>>  
>> I have been at organizations where this is broader than those 4 items, and at places where those 4 sre strickly adhered to, and no other parsing issue are identified as failing 4.1.1.
>>  
>> Steve Faulkners tool and blog (https://www.paciellogroup.com/blog/2015/11/wcag-2-0-parsing-criterion-is-a-pita/ <https://www.paciellogroup.com/blog/2015/11/wcag-2-0-parsing-criterion-is-a-pita/>) seem to support the 4 items only.
>>  
>>  
>> * katie *
>>  
>> Katie Haritos-Shea 
>> Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
>>  
>> Cell: 703-371-5545 <tel:703-371-5545> |  <mailto:ryladog@gmail.com>ryladog@gmail.com <mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 <tel:703-371-5545>
>>  
>>  
> 
> 
> -- 
> Christophe Strobbe
> Akademischer Mitarbeiter
> Responsive Media Experience Research Group (REMEX)
> Hochschule der Medien
> Nobelstraße 10
> 70569 Stuttgart
> Tel. +49 711 8923 2749
> 
> “It is possible to make a living making free software for freedom 
> instead of closed-source proprietary malware for cops.” 
> Jacob Appelbaum, 
> <http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/> <http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>