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

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

<divid="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 **|****ryladog@gmail.com*
> <mailto:ryladog@gmail.com>***|****Oakton, VA **|****LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/>***|****Office:
> 703-371-5545*
>
>  
>
> *From:*Alastair Campbell [mailto:acampbell@nomensa.com]
> *Sent:* Friday, January 29, 2016 9:52 AM
> *To:* 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,
>
>  
>
> 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 **|****ryladog@gmail.com*
> <mailto:ryladog@gmail.com>***|****Oakton, VA **|****LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/>***|****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/>