Re: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG

Strictly speaking malformed aria would be limited to 1.3.1, or 4.1.2 (or
perhaps 1.1.1 on image or input name messups.)
Not what I would want... would love to include in 4.1.1 but it is not
specified there. Wai-aria wasn't around yet.

perhaps add it in the extensions.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jan 29, 2016 at 1:00 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com
> wrote:

> 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 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <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>
> 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 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <703-371-5545>*
>
>
>
> *From:* Gregg Vanderheiden [mailto:gregg@raisingthefloor.org
> <gregg@raisingthefloor.org>]
> *Sent:* Friday, January 29, 2016 12:21 PM
> *To:* 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
>
>
>
> 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 <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 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <703-371-5545>*
>
>
>
> *From:* Alastair Campbell [mailto:acampbell@nomensa.com
> <acampbell@nomensa.com>]
> *Sent:* Friday, January 29, 2016 9:52 AM
> *To:* Katie Haritos-Shea GMAIL <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 <703-371-5545> **|* *ryladog@gmail.com
> <ryladog@gmail.com>* *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <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/>
>
>
>