- From: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
- Date: Fri, 29 Jan 2016 13:00:58 -0500
- To: "'Gregg Vanderheiden RTF'" <gregg@raisingthefloor.org>, "'GLWAI Guidelines WG org'" <w3c-wai-gl@w3.org>
- Cc: "'GLWAI Guidelines WG org'" <w3c-wai-gl@w3.org>
- Message-ID: <058e01d15abf$02d7b740$088725c0$@gmail.com>
Yes, I remember all that, I am not saying full conformance to a spec, and never have (especially the doctype thing - that kicked everybodies butt for a while). What I am asking is: would you consider “applying the “according to spec” for content/technology parsing errors that clearly DO affect AT” as a broad application of 4.1.1 – for those issues that do not fall under the 4 identified – along with the limitation on the NOTE wording? Yes, I am digging very deep. So are many other, especially as ARIA, SVG and other technologies are coming along. Many have said ARIA is out because it is not a markup language. However, the text says “content implemented using markup languages” – and “content implementedusing markup” in my mind that include ARIA. Again, hard question Gregg, what say you? * 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 RTF [mailto:gregg@raisingthefloor.org] Sent: Friday, January 29, 2016 12:53 PM To: Katie Haritos-Shea <ryladog@gmail.com> Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org> Subject: Re: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG Boy you are digging into the one provision that is sort of technology specific. We had a hard time including that one for that reason - but it was part of the consensus process. We only cited those for bits because they were the only ones with any evidence of Causing problems for assistive technologies. We specifically did not require that everything be done to spec because there was no evidence that following a specification completely was needed for accessibility. In fact there were some places where it was shown that following a specification religiously actually prevented pages from being as accessible as otherwise as possible. The provision should not be read as” use everything exactly to specification” although there was consensus that in general that is very good practice. Making it a requirement for accessibility however went beyond what our mandate was. Our mandate was to only address things that addressed accessibility and not carry the torch for good interface or other practice that did not directly impact accessibility in any known way. gregg On Jan 29, 2016, at 11:47 AM, Katie Haritos-Shea GMAIL <ryladog@gmail.com <mailto:ryladog@gmail.com> > wrote: Gregg, Thanks for your input here. I think this brings us back to the question of what is covered in 4.1.1? Certainly all parsing errors do not affect AT negatively, but certainly more than those 4 listed in the spec do – so, as you say…..I have usually gone with “using the technology to spec” part, for HTML and other languages and markup used to generate content – starting with those 4 that appear to be HTML specific, but then also applying the “according to spec” for content/technology parsing errors that clearly DO affect AT. What say you about this Gregg (oh learned mentor-mine)? And Christophe, See I think, under the note for 4.1.1 (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.), that “misspelling their names and values” , are errors, is covered – and - very clearly CAN affect/effect AT (such as if those misspelled/incorrect attribute names and values are related to an ID). * 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: Friday, January 29, 2016 12:21 PM To: 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 - ARIA? and How? - and SVG 4.1.1 was intended to protect AT against errors (or sloppy code practices) that exist in a page because browsers detect and auto-repair them — so the authors don’t notice them and fix them themselves. In order to not require AT to all have to implement all of these auto repair functionalities, 4.1.1 was added requiring authors to use technologies according to their specification — even if browsers would repair the bad code so ordinary users would not experience the bug. In this manner, AT could rely on the specification. 4.1.2 Was designed to ensure that authors included all the bits they needed to, especially when creating custom Elements, or in any case where a technology was used that did not automatically result in these capabilities being available to assistive technologies. gregg On Jan 29, 2016, at 9:59 AM, Christophe Strobbe < <mailto:strobbe@hdm-stuttgart.de> strobbe@hdm-stuttgart.de> wrote: Hi Katie, Alistair, On 29/01/2016 16:23, Katie Haritos-Shea GMAIL wrote: Hi Alistair, I appreciate your thoughts on this…… I happen to be one of those people who like to call errors under the major SC intent that it fails, which is often more than one SC. I would say that malformed is the 4.1.1 main issue with 4.1.2 and depending on the component we are talking about probably 1.3.1 as outcomes of a 4.1.1 error. It isn't very clear to me who ARIA attributes can be malformed except by misspelling their names and values. This type of errors would not be covered by SC 4.1.1 but would probably lead to SC 4.1.2 failures. For example, if you accidentally write <div id="nav" rol="navigation"> instead of <div id="nav" role="navigation"> then the role of the div will not be programmatically determinable (SC 4.1.2). But if you write <nav id="nav" rol="navigation"> instead of <nav id="nav" role="navigation"> then the role of the element is still programmatically determinable (at least for UAs and ATs with accessibility support for HTML5's nav element). According to some 4.1.1 hardliners, who have seen it as limited to those 4 issues and on HTML only, they could call it a 4.1.2. In my mind, 4.1.1 is about mistakes/unknowingly-invalid-use (other than custom design –which is clearly 4.1.2) in coding – whereas 4.1.2 is about designing specifically with user agents, AAPI and AT interoperability in mind when building custom components whether that is in HTML, scripting or what-have-you. If elements are not correctly nested (cf. Alistair's message), that would be covered by SC 4.1.1. But not all validation errors and other markup errors are violations of SC 4.1.1; only the types of errors that are listed there should be considered as violations of this SC. If you the code you produce doesn't match an ARIA design pattern, then, strictly speaking, you can't claim to be using the intended technique. It's the code that needs to conform to WCAG, not the developer's intentions. (That's the approach in the WCAG techniques: if your code does not pass the test procedure in a specific technique, you can't claim that your code uses that technique.) Best regards, Christophe My 2 cents….:-) * 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: Alastair Campbell [ <mailto:acampbell@nomensa.com> mailto:acampbell@nomensa.com] Sent: Friday, January 29, 2016 9:52 AM To: Katie Haritos-Shea GMAIL <mailto:ryladog@gmail.com> <ryladog@gmail.com> Subject: Re: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG Hi Katie, Responding off list as I’m very late to the discussion – but wouldn’t 4.1.2 (Name/role/value) cover issues of malformed ARIA? If the nesting is off and it doesn’t match an ARIA design pattern (I.e. cannot be programmatically determined), wouldn’t that catch errors of that nature? I’m struggling to think of examples where something could be malformed but still be programmatically determined. Cheers, -Alastair PS. Please feel free to reply on list if you think this is adding to the discussion. From: Katie Haritos-Shea GMAIL Date: Wednesday, 13 January 2016 at 21:14 Subject: RE: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG 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 -- 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 Friday, 29 January 2016 18:01:31 UTC