- From: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
- Date: Wed, 13 Jan 2016 16:32:47 -0500
- To: "'Christophe Strobbe'" <strobbe@hdm-stuttgart.de>, "'GLWAI Guidelines WG org'" <w3c-wai-gl@w3.org>
- Message-ID: <05ec01d14e49$f3086d90$d91948b0$@gmail.com>
Perfect Christophe, I appreciate you clarity here. Thank you! I woud like to know what others think in regards to my questions around ARIA and SVG for 4.1.1………… * katie * Katie Haritos-Shea Senior Accessibility SME (WCAG/Section 508/ADA/AODA) Cell: 703-371-5545 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 From: Christophe Strobbe [mailto:strobbe@hdm-stuttgart.de] Sent: Wednesday, January 13, 2016 4:25 PM To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>; Katie Haritos-Shea GMAIL <ryladog@gmail.com> Subject: RE: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG Hi Katie, Just to make my position doubly clear ;-) 1. the third subcriterion of SC 4.1.1 would apply to ARIA; 2. SC 4.1.1 definitely applies to content implemented in SVG. Best regards, Christophe Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com> > hat am 13. Januar 2016 um 22:14 geschrieben: Christophe, ARIA Thanks. This is what I was getting at. I am trying to get folks to think about 4.1.1 Parsing in our current and near future web technology era. You said “But if you use the same ARIA attribute twice on the same element, that would be covered by SC 4.1.1 and would be considered as a violation, unless you can find something in the ARIA spec that justifies duplicate attributes on the same element.” So we would agree that there are some aspects of 4.1.1 Parsing that would be applicable to ARIA. It would be helpful to identify what those things might be for ARIA. Given the 4 items below, what do people think?: 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, ARIA YES? 4. and any IDs are unique, except where the specifications allow these features. In my mind #2 here is very applicable because the nesting of ARIA can wreck havoc on users of AT, but I would love to hear what others think…… SVG Also, do others agree that all of 4.1.1 Parsing is applicable to SVG? I do, and as SVG continues to re-emerge and gain greater traction with improved WYSIWYG tools, and hopefully accessibility features, I think it can certainly have impacts on AT and their users. * katie * Katie Haritos-Shea Senior Accessibility SME (WCAG/Section 508/ADA/AODA) Cell: 703-371-5545 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 From: Christophe Strobbe [mailto:strobbe@hdm-stuttgart.de] Sent: Wednesday, January 13, 2016 3:42 PM To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >; Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com> > Subject: RE: Question #2 on 4.1.1 Parsing - what it covers - markup-wise Hi Katie, WCAG applies to content, not to markup languages; markup languages (which are described by technical specifications) are not content, just formats that you can use for content. So WCAG has to say, "in *content* implemented using markup languages" (or something similar). HTML content with ARIA attibutes is still content using markup, so SC 4.1.1 applies to it. But not every issue with ARIA markup would be covered by SC 4.1.1. For example, if you misspell the name of ARIA attribute, you are basically inventing a new non-ARIA attribute; this would not be covered by the SC. But if you use the same ARIA attribute twice on the same element, that would be covered by SC 4.1.1 and would be considered as a violation, unless you can find something in the ARIA spec that justifies duplicate attributes on the same element. (If the duplicate ARIA attributes have the same value, there is hopefully no real accessibility issue.) In cases where ARIA is not used according to the ARIA specification but somehow still meets SC 4.1.1, you should probably look at SC 4.1.2, which covers the names, roles and values of UI components. Best regards, Christophe Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com> > hat am 13. Januar 2016 um 16:45 geschrieben: Christophe, Thanks for the SGML history and proper-use-of-English lessons, many will profit from it . And is happens, I was on the WG at that time….:-) But here is what the SC text says……”In content implemented using markup languages”…..it doesn’t say “markup languages shall…” ARIA (as a vocaulary) is used in content implemented using markup languages. It has attributes, has nesting requirements, it utilizes IDs, and has attribute values. I know what we MEANT at the time WCAG 2 was written. What does it mean now? ARIA is used to improve compatability with AT. What if it is not used according to it’s spec, under those 4 broad items, whose incorrectness will affect how user of AT are able to utilize the content? * katie * Katie Haritos-Shea Senior Accessibility SME (WCAG/Section 508/ADA/AODA) Cell: 703-371-5545 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] Sent: Wednesday, January 13, 2016 7:01 AM To: Christophe Strobbe <strobbe@hdm-stuttgart.de <mailto:strobbe@hdm-stuttgart.de> > Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> > Subject: 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 <mailto: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 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | 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 <mailto:ryladog@gmail.com> <ryladog@gmail.com> Cc: WCAG <mailto:w3c-wai-gl@w3.org> <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 < <mailto:ryladog@gmail.com> 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 | <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 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/>
Received on Wednesday, 13 January 2016 21:33:23 UTC