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

Katie Haritos-Shea wrote:
>
> 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……

Except, as written, not. ARIA is comprised of attributes and attribute values that are applied to elements (whether those elements themselves have any semantic meaning or not). There are no ARIA elements, and 'elements' is specifically what is being called for in #1, #2, and #3 (and #4 - unique IDs - is completely out of scope, as @ID is also an attribute, and you cannot attach an attribute to another attribute...)

So the wording here is suspect for #2, as while there is indeed issues with the order with which some aria attributes are nested (menu and menu item come easily to mind - gotta get them in the right order) they are still only attributes, and attributes can be attached to elements in any order (for example <img alt="foo" id="bar" class="css" src="path">; while it may "look" unusual as traditionally the 'src' value comes first, is both perfectly valid and will 'render' as intended.)

This leaves us in a situation where I believe we'll likely need to mint a new WCAG.NEXT rule (or rules) around correct usage of ARIA, but it also (I believe) means that 4.1.1 has little impact on ARIA directly, outside of #3 (which Christophe also notes), and even then, does it cause any real issue? <div role="banner" id="foobar" class="css" role="banner> is technically incorrect, but does it have any impact on the end user outcome?

>
> 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.

I tend to agree here, as SVG is an element-based markup language as well. Not having a lot of experience with SVG, I'm curious however how fault-tolerant SVG is overall - is it rigorous like XML, or loose like HTML? If it is more rigorous (i.e. get it right or your image doesn't render) then I suspect "Parsing" issues in and of themselves, especially the four in question in 4.1.1 will likely be enough, and may not even be called on that often because of the rigor factor. (In other words, parsing issues would have an impact on *all* users, not just those dependent on AT, etc.) 

JF

Received on Wednesday, 13 January 2016 21:47:40 UTC