How to test for criterion 1.3.6 identify purpose and what would fail it

[DhruvPatel2502]

While performing level AAA testing, I discovered that criteria 1.3.6, "Identify Purpose," shares many of the same requirements as criterion 4.1.2, "Name, Role, Value." As a result, I was uncertain of how to determine if anything meets or fails this criterion because there is no mention of a failure connected to it. So, how can we determine whether a website meets or fails this criterion?

[kimviens]

Thank you for your question Dhruv. I too I am stuck on this, has anyone ever failed a website for this criterion?

[kimviens]

I am willing to suggest that this criteria can be tested by using an assistive technology like a screen reader. Screen readers have the ability to pull up a dialog listing all: links, headings, buttons, controls, landmarks... From there we can see if every element can be understood without the context of the content.

[detlevhfischer]

Looking at the Quickref, the only existing Technique currently provided for 1.3.6 is ARIA11 (Using ARIA landmarks...). This would work for regions like navigation only when tools or plugins would exisit that make such regions visually apparent as well. Landmarks provide structure to non-visual users and do nothing for sighted users, while one main focus of 1.3.5 and 1.3.6 seems to be sighted users with cognitive issues who struggle with identifying content, including identifying input via text labels.

I guess regarding inputs, the most common approach for satisfying 1.3.6 would be the same as for 1.3.5: using the autocomplete attribute as a language-independent way of communicating what kind input is expected. From that follows the appropriate test. Strangely, there seems to be no such Technique referenced in the Quickref for 1.3.5 and 1.3.6. Maybe it hasn't been written yet.

The main point of 1.3.5 and 1.3.6 regarding inputs was supposed to be to provide a generic identification of input purpose (independent of, and going beyond, the HTML type attribute). The idea was that new assistive technologies (e.g. browser plugins) could use that info to present the input purpose in some other (possibly not texual) form.

So, @kimviens , using the screen reader to test this would cover regions but does not seem sufficient. There are bookmarklets checking for the existence of autocomplete attributes (no endorsement implied, haven't tried it yet) so the autocomplete values used (if any) could be compared to the inputs' respective purpose.

The basic problem with this "hen and egg" scenario remains that nearly five years after the introcuction of 1.3.5 and 1.3.6 in WCAG 2.1, no AT whatsoever has appeared that uses an input purpose attribute (currently autocomplete as a stand-in for future more generic metadata attributes) or landmarks as a hook for other presentations like icon overlays. (Correct me if I am wrong and something usable - i.e., not some clunky demo - does exist, please!). Having autocomplete assist users in filling in fields is often a welcome side effect but was to the actual intent of 1.3.5. and 1.3.6.

[patrickhlauke]

agree that 1.3.6 is eminently vague. I see it a bit as a stricter version of 1.3.1 Info and Relationships ... while 1.3.1 is scoped just to making sure the underlying structure of a page reflects its visual presentation, 1.3.6 goes further in demanding that the markup should convey often implicit structures in a more unambiguous (if possible) way. (as an aside, remembering lots of lengthy discussions back and forth about whether or not not using <header> or <footer> etc would be a failure of 1.3.1 when visually they're styled in a particular distinct way or not, and not being able to come up with a definitive cut-off point for when something passes versus something fails, so to an extent I personally see 1.3.6 as trying to patch this gap in 1.3.1)

i'd add a bit more nuance here though to @detlevhfischer's initial thoughts. I do think ARIA landmarks do play a role here...while yes, the idea of the SC is that it can benefit sighted users, and ARIA landmarks primarily serve non-sighted/AT users, the SC itself asks for adding "programmatically determinable" information. landmarks satisfy this. The idea then is that a sighted user may be able to have a bookmarklet, custom CSS, some mythical/hypothetical feature in their user agent, that can also make this programmatically determinable structural information visible to them.

but how to determine what passes or fails this SC is...wooly, at best. comes down, in my view, to "is the page using all possible techniques, such as landmarks etc, to give as much information as possible about its structure and the purpose of its various component elements/interactive elements?" ... it's very open-ended

[detlevhfischer]

@patrickhlauke

I'd add a bit more nuance here though to @detlevhfischer's initial thoughts. I do think ARIA landmarks do play a role here

Yeah - I looked up 1.3.6 and realised the focus of my answer was too narrow, have updated it while you were writing...

[alastc]

@detlevhfischer - there are some pluggins which apply icons to the content. I know they exist but are relatively specialist (even within accessibility) and I haven't tried one myself. I don't know if they utilize autocomplete or landmarks, but they should.

I'd also note that landmarks aren't required by 1.3.1 (there are other techniques), but my read of 1.3.6 is that landmarks are generally required (assuming there are different areas of a page).

[patrickhlauke]

I'd also note that landmarks aren't required by 1.3.1 (there are other techniques), but my read of 1.3.6 is that landmarks are generally required (assuming there are different areas of a page).

yup, hence my high-level "1.3.6 is a bit like a stricter version of 1.3.1" gut-feel

[detlevhfischer]

@alastc

there are some pluggins which apply icons to the content

Ah, OK, I see. Do you have a link to one or any of them?

[patrickhlauke]

I think the only plugins/bookmarklets I've seen were those created at the time to justify making the SC pass / demonstrate some "implementation"...

[patrickhlauke]

coming back to this after a few months... are we (AGWG) agreed/resigned to the fact that this SC, in practice, currently really just shakes out to "use landmark elements (<header>,<nav>,<main>, etc) or ARIA landmarks (role="main", etc)" ? and, in essence, the requirements from 1.3.5 Identify Input Purpose (for the "User Interface Components") to an extent? there's no other official way of conveying purpose really (I'd say the mention of "microdata" is a red herring, as is the suggestion that coga-simplification or similar is in any way supported/viable as a technology)

[detlevhfischer]

@patrickhlauke For what it's worth, I agree.