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:44PM

..and to close the circle, when machines can express the intent of the
input in different modalities, it ultimately *DOES* make it more
understandable by the end user, but again this is a Perceivable SC, and not
an Understandable SC, so the perceivability is the more important goal of
this SC.

JF

On Thu, Jul 26, 2018 at 12:26 AM, John Foliot < <EMAIL REMOVED> > wrote:

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



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion