WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: John Foliot
Date: Jul 25, 2018 11:26PM

Hi Jared,

A tricky but important discussion. Comments in line:

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

No, not "...in a meaningful way", but rather "...in different modalities".
I believe there is a distinction here that is underscoring our differing
interpretations.

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

You are correct, the software doesn't need to know the "what" of the input
(which is covered by the accessible name generated by the label), but it
*DOES* need to know how to present it in "different modalities". Given that
the accessible name is going to be effectively always a random string
(either because it is in English, or a non-English language) or because the
"label" could have variants in expression (nickname, nic, handle, tag all
would currently map to the @autocomplete value of 'nickname'), the
accessible name does not provide what is required to meet this SC, because
the values of accessible name will always be random author supplied values.

To be able to express the concept of the input, to present it in "different
modalities" (including non-text alternatives such as icons), you need a
standardized look-up table - aka a taxonomy. The explicitly defined values
that are the token values of @autocomplete meet that need today.

Importantly for WCAG 2.1, we've also published those values and definitions
verbatim in WCAG 2.1 as well, to ensure that those definitions don't change
from out under our feet (due to potential changes to future versions of
HTML), and because the WG anticipates other mechanisms to emerge (during
the Personalization work) to attach those values to the inputs: the desire
being that one day we'll have multiple mechanisms (in a similar way that we
can provide the accessible name of an image using either @alt, @aria-label,
or @aria-labelledby today).

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

I disagree. The majority of use-cases that drove the development of this
Success Criteria were informed by the documented needs of users with
cognitive disabilities. For many of those users who have issues with
processing text, they would traditionally require symbols and iconography
to effectively communicate. Question, how would software know how to
express "Số thẻ tín dụng" or "رقم بطاقة الائتمان" as a symbol?

The intention of this Success Criteria is not "the name (label) for the
input is understood by the end user" (a form of access), but rather that
that purpose of the input can be expressed in "different modalities" (i.e.,
as a symbol). Subtle, yes, but quite different as well, due to the need for
a conversion look-up table - the taxonomy.

In other words, for the end user to be able to "Perceive" the reason (a
1.x.x numbered SC), the requirement is closer to "conversion" (aka the
ability to "*Identify* the Input Purpose" and express that in different
modalities) as opposed to "interpretation" (aka make it "Understandable", a
3.x.x numbered SC)

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

That is a matter of interpretation. I'm sorry it is less than clear to you,
but the language was reviewed multiple times, along with documented
discussion that lead to the final language, and the Working Group felt that
this language does express the requirement clearly. I agree that currently
the Understanding document attached to this SC is less than clear, and that
needs to be addressed by the Working Group quickly. I've already confirmed
that I've taken ownership of that task.


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

No, because the defined term of "programmatically determinable" does not
equal "understandable by the end user", but rather that information (or for
row headers and page titles the "semantics" of those elements) can be
(consistently) identified, so that it can be expressed in different
modalities. Looking at those existing 2.0 SC that use this defined term:

Success Criterion 1.3.1 Info and Relationships
​
(Level A)
Information, structure, and relationships conveyed through presentation can
be *programmatically determined* or are available in text.


To achieve success in any permutation of interpreting this SC (given it
remains the "kitchen sink" of SC) always tracks back to shared common
understanding. The defined semantics of HTML is one such form of shared
understanding
​, and those semantics, for the intent of this SC, are supplied via the
semantics of those HTML elements​
. As an end user, you may not ever be able to understand what <h1>இது ஒரு
தலைப்பு</h1> means, but programmatically, machines will always we able to
unequivocally determine that the content is in fact a heading at level 1.
That's why <div id="first level heading"> fails this SC, because what I
expressed in readable (and for this mailing list audience "understandable")
junk code cannot be "programmatically determined" by machines.

Machines will always be able to determine the difference between a <th> and
a <td>, even if through styling or scripting there may never be a visual
difference on screen for sighted users
​.​
BUT, through alternate or user style sheets that difference *could* be
expressed in a different modality, i.e. apply a different style
​,​
​ because the difference of those two types of table cells can be
determined programmatically, and so modification can be achieved - i.e.,
present the information in a different modality visually, and AT such as
screen readers are programmed to convey the difference to those users.​



Success Criterion 1.3.2 Meaningful Sequence
​
(Level A)
When the sequence in which content is presented affects its meaning, a
correct reading sequence can be *programmatically determined*.


This one is slightly trickier, but the same argument remains applicable.

Reading order can be programmatically determined using a number of
different mechanisms. One example: by identifying the native language of
the document as Hebrew, applications that need to output the text in an
ordered reading sequence in an audio form is already programmed to ensure
R-L reading of the text. For the programmatic determination however you
must always trace back to a fixed list (lang="he" or "heb" and not
lang="Hebrew" - i.e., by using fixed values defined by ISO 639 (
https://iso639-3.sil.org/code_tables/639/data/h) - another "look-up table"
​ taht can be referenced by machines​
)

Then there is a default tabbing order, which is also inherent to reading
order; but one that can be modified by using tabindex. HOWEVER, the values
that you can use for tabindex is restricted to (a fixed list of) numeric
values: 0, positive integers, or -1. Using tabindex="two" does not meet the
requirement, in the same way that tabindex="deux" does not (equal values,
but in different languages) because software
​ today​
is not equipped for heuristic capabilities to translate the wrong value
(deux) to the correct value (2). Perhaps in the future AI will be able to
achieve this, but today that option does not exist (at least not at scale -
IBM Watson "might" have this capacity today, not sure...)


Success Criterion 3.1.1 Language of Page
​
(Level A)
The default human language of each Web page can be *programmatically
determined*.

Success Criterion 3.1.2 Language of Parts
​
(Level AA)
The human language of each passage or phrase in the content can be
*programmatically
determined* except for proper names, technical terms, words of
indeterminate language, and words or phrases that have become part of the
vernacular of the immediately surrounding text.


As in the first Meaningful Sequence example above (determining reading
order in part by declaring the language) both of these SC are solely
dependent on a fixed taxonomy list that is the ISO 639 defined list. No
other values will achieve success. While this most often impacts screen
readers, for those software tools to be able to do "on the fly" language
switching (SC 3.1.2), those values must be encoded using the ISO codes to
be output in a different modality (in this case, a different language
profile)
​. Once again, success is achieved because machines have a stable
references to make the changes in modality, and user success derived by
these SC is directly dependent on those outcomes.


Success Criterion 4.1.2 Name, Role, Value
​
(Level A)
For all user interface components (including but not limited to: form
elements, links and components generated by scripts), the name and role can
be *programmatically determined*; states, properties, and values that can
be set by the user can be programmatically set; and notification of changes
to these items is available to user agents, including assistive
technologies.


This SC only requires that "name" and "role" be programmatically
determined.

For 'name' the value string can be localized, but the mechanism by which
you associate a name
​ (making it programmatically determinable)​
to an element or component is limited to a fixed number of ways, using the
​ machine-understandable​
semantics of HTML (see SC 1.3.1).

For the 'role' to be programmatically identified, it has to take one of the
fixed list of defined values that are valid for that attribute: authors
can't make up new values, because software wouldn't know what to do with
those values, so the intent of the author cannot be 'determined'. The
lookup table
​ for @role​
is defined in ARIA as
​w
idget roles (https://www.w3.org/WAI/PF/aria/roles#widget_roles), document
structure (https://www.w3.org/WAI/PF/aria/roles#document_structure_roles)
​,​
or landmark roles (https://www.w3.org/WAI/PF/aria/roles#landmark_roles). No
machine on earth (that I know of) would be able to programmatically
determine and express in a different modality
​ the following:​
*role="WebAIM_Widget"*.

As such, I assert your interpretation of the definition of
"programmatically determinable" is incorrect, leading to your
misunderstanding of this SC.

For every instance of the use of the term "programmatically determinable"
in WCAG 2.0 and 2.1, achieving success is dependent on
​ machine understanding of​
a taxonomy of sorts, whether a fixed list of roles defined in ARIA, the
fixed input values defined as part of @autocomplete, or the limited and
defined semantics that is HTML (as non-semantic elements such as <div> or
<span> lack any native semantics and thus fail to meet SC 1.3.1 without
further ARIA semantics being attached). And while in many ways
"programmatically determinable" *could* be a synonym of Understanding, this
term as used in WCAG today means the understanding is not by the end user,
but rather by machines, so that machines can express the concept "in
different modalities".


> This logic doesn't fly.

Respectfully disagree.
​ Based on the normative definition of "programmatically determinable"​
(which I've attempted to defend above) and the WG's understanding of that
definition, the
​
intent of this
​ SC​
is
​ indeed​
to require authors to support universal machine understandability of input
purpose
​​ (so that it can be *expressed in different modalities* - the key phrase
in this discussion and the definition of that term).


JF



On Wed, Jul 25, 2018 at 3:17 PM, Jared Smith < <EMAIL REMOVED> > wrote:
>
> 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.
>
> Jared
> > > > --
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion