WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 - 1.3.5 - How to capture a violation?


From: Jared Smith
Date: Jul 25, 2018 2:17PM

John Foliot wrote:

> *determined by software* from author-supplied data provided *in a way that
> different user agents*, including assistive technologies, *can extract and
> present this information to users in different modalities*

I think this is a key in our differing interpretations. This
definition doesn't state that the software has to make sense of the
information, only that it must "extract and present" it to the user in
a meaningful way.

> Both of these functions work because no matter what you as an
> author has supplied as the text label (Accessible Name), the machine
> readable token remains constant for the software to determine.

But the software doesn't need to determine what the fields are for -
the user does! How the software gets the information and presents it
to the user shouldn't matter - it's that the information is presented
to and is "perceivable" and "understandable" by the user that results
in actual accessibility.

> If I label an input *Số thẻ tín dụng *for
> example, how will software understand that?

It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
it's fully accessible to that user.

If the actual intent of this is to require authors to support
universal machine understandability of input purpose regardless of
language or context, then the SC falls well short of making this
remotely apparent. And if this is done by defining "programmatically
determined" to mean that a computer must always make sense of it, then
authors must also be limited to pre-defined label texts, row headers,
page titles, which must also be "programmatically determined", no?
This logic doesn't fly.

> But if I also programmatically
> link the accessible name (*Số thẻ tín dụng*) to a machine-understandable
> value (cc-number), *THEN* machines can start to figure it out as well and
> "....
> extract and present this information to users in different modalities
> " (such as the two examples I mentioned).**

Yep, absolutely - they can "figure it out *as well*", but the success
criterion does not require that authors support this additional
machine understanding *in addition to* providing a programmatic label
that presents the purpose of the field.

> I agree this is less than clear or obvious in the Understanding
> documentation today

My bigger concern is that if I, as someone that has contributed
significantly to WCAG and has read and written 1000s of pages of
documentation on it, has no idea what this success criterion
presumably requires (assuming this interpretation is the correct one),
then I would have no reasonable expectation that anyone else would
either. I'm rather uncomfortable with non-normative documentation
significantly altering and expanding the meaning of normative success
criteria. My recommendation would be to support the success criterion
text itself, as is, and look to address this broader desire and intent
in a future version.