Re: Section 508 mapping of WCAG 2 to FPC

On 27/02/2023 16:42, Michael Gower wrote:
> I’ll take a shot, based on churning through this for 508 Refresh, etc. 
>   Answered inline, <mg>like this</mg>

Sorry Michael, late reply, but first of all thanks for taking the time.

> * 1.4.1 Use of colour: I assume this doesn't fall under "Without Vision"
> if the information conveyed through just colour is also conveyed
> programmatically (so that it's announced by a screen reader, for instance)
> 
> <mg> Not correct
> Please see the third note:
> “This criterion does not directly address the needs of users with 
> assistive technologies. It aims to ensure that sighted users who cannot 
> distinguish between some colors can still understand content. How 
> information is conveyed to assistive technology users is covered 
> separately in other criteria,…
> 
> </mg>

But that's my point: a failure of 1.4.1 would NOT necessarily fall under 
"Without Vision", as 1.4.1 is effectively only concerned with sighted 
users/visual aspects. So failing 1.4.1 does *not* immediately mean a 
"does not support" under the "Without Vision" section.

> 
> * 3.1.1 Language of page: why is this marked under "Without Hearing" and
> "Limited Hearing"? How are these groups affected?
> 
> <mg>The fourth bullet under Benefits states: “
> 
>   * people who rely on captions for synchronized media.
> 
> Under the intent section is also says:
> 
> Media players can show captions correctly.
> 
> I find it a stretch to say that the set language of the page is likely 
> to have any effect on the captions. It doesn’t align with my experience, 
> which is that a video and it’s possible captions are rarely posted by 
> the same person who created the page. In fact, anyone who relies on a 
> page’s lang attribute to make a decision on the video language may be in 
> for a surprise. But I freely admit that my experience is pretty limited. 
> </mg>

So this would likely be a heavily caveated mapping, not a direct 'if a 
page fails 3.1.1, it also "does not support" under "Without Hearing" and 
"Limited Hearing".

> * 3.1.2 Language of parts: why is this marked under "Without Hearing"
> and "Limited Hearing"? How are these groups affected?
> 
> <mg> The fourth bullet of the Benefits states:
> 
>   * people who rely on captions to recognize language changes in the
>     soundtrack of synchronized media content.
> 
> I think maybe someone is confusing subtitles with captions here? But 
> even then, I think there is a pretty clear convention that information 
> that is intended to be understood by a speaker of the source material’s 
> native language is translated into the subtitle language.
> 
> For news reporting, where someone responds in an interview in a 
> different language than the intended viewing audience, one of two things 
> happens: the response is translated in the audio soundtrack (as a voice 
> over), or subtitles are provided. In the former scenario, the captions 
> at best would indicate in text that another language was spoken before 
> captioning the voice-over translation. In the latter, there would be no 
> need for captions, since that function has been provided by the subtitles.
> 
> On those rare occasions where multiple languages are in a soundtrack and 
> the meaning of both are provided in one language (as opposed to just 
> displaying “[French spoken]” etc), that is normally indicated textually 
> in the subtitles themselves (e.g., not programmatically). Otherwise, the 
> language of subtitles and captions are provided textually as a options 
> in a menu.
> 
> Finally, if I’m submitting a video, I’ve been prompted to indicate the 
> language for ASR. I can see there being a potential that there could be 
> an opportunity to indicate the language.
> 
> It would be useful to hear someone who is familiar with current 
> technologies to understand how likely/common a programmatic indicator 
> comes into play on language of parts.</mg>

Likewise then, this would likely be a heavily caveated mapping, not a 
direct 'if a page fails 3.1.2, it also "does not support" under "Without 
Hearing" and "Limited Hearing".

> * 3.2.4 Consistent Identification: it's unclear to me why this has also
> been marked under "Limited Manipulation"
> 
> <mg>Unknown</mg>

I'll hazard a guess that this is...an incorrect mapping.

> * 3.3.1 Error identification: am I correct in assuming that "Without
> Perception of Colour" only applies if the reason why something fails
> this SC is because they're using colour alone to indicate an error?
> Otherwise, if errors are not indicated in general, would this not be
> something that fails for *all* groups?
> 
> <mg>If colour was used, it would either fail Perception or it would fail 
> Use of Color (if in the instructions). I think the germane part of this 
> SC is that ‘information is described in text’. This failure is about the 
> absence of identification of error and description in text.
> 
> The ‘text’ and ‘described’ parts are key, as noted in Benefits.</mg>

So again, my point is that it's not a direct mapping, but it only maps 
to a "does not support" under "Without Perception of Colour" is it DID 
indeed rely on colour alone.

> * 3.3.2 Labels of instructions: while I understand why this would affect
> people with "Limited Language, Cognitive, and Learning Abilities", it's
> unclear why "Limited Vision" has also been singled out as a group
> affected by this.
> 
> <mg>I think the tie-in is having a visual label for a control. As stated 
> in the Understanding, this is about the existence, by which I infer 
> visual existence:
> This Success Criterion does not require that labels or instructions be 
> correctly marked up, identified, or associated with their respective 
> controls
> 
> I agree it’s very weakly linked in the Understanding doc – and that 
> proximity of label is a bigger (and specified) requirement for limited 
> vision. </mg>

So I'd contend that this mapping needs to be updated, or at least 
heavily caveated, with regards to the "Limited Vision" mapping.

> * 3.3.3 Error suggestion: am I right in thinking that this has been
> marked under "Limited Manipulation" under the scenario where a site/app
> should offer an easy way for a user to select (e.g. from a list, or
> radio buttons) the correct value they intended to use - rather than in
> cases where the solution would be to provide error suggestion in text
> (leaving the user to still enter it/correct their entry manually)?
> 
> <mg>I agree this seems misplaced. The benefit statement is stretching it:
> 
> People with motion impairment can reduce the number of times they need 
> to change an input value.
> 
> Partly this is a result of how unnecessarily (and poorly) isolated Error 
> Suggestion is from Error Identification. I think Limited Manipulation 
> should be removed. </mg>

+1

> * 3.3.4 Error prevention (legal, financial, data): wondering why this
> has been marked as affecting almost all groups, *but* with the notable
> omission of "Without Speech" and "Limited Reach and Strength". Is this
> just because there's an overall decision that *none* of the WCAG SCs
> relate to those two categories? If the intention is that a lack of error
> prevention affects everybody and is important enough to flag, then I
> would have thought this would affect *all* groups. Otherwise, I'd be
> interested to know if there's specific rationales for the groups that
> *were* marked as being affected by a failure of this criterion (and if
> there's any particular nuance of failure that would only relate to
> specific groups - e.g. I can't currently think of a scenario where a
> lack of error prevention may be problematic for a user "Without Hearing"
> and "Without Vision" but fine for a user with "Limited Reach and Strength")
> 
> <mg>I concur that it should be all groups. I can think of situations 
> where any user may have inadvertently done something as a result of 
> their AT, input or understanding. All can apply.<mg>

That then brings up the question why there are not other SCs that will 
likely affect all users that *haven't* been mapped to all user groups. 
For instance, 3.3.1 Error identification ... if we're saying 3.3.4 
affects all users, then so does 3.3.1. Just seems a bit arbitrary.

> 
> * 4.1.1 Parsing: am I right in thinking that this has been flagged under
> "Limited Manipulation" only for cases where incorrect/broken markup also
> results in problems relating to, say, keyboard operation/focus order?
> Further, I'd be interested to know what kinds of failures of this SC
> would affect people with "Limited Language, Cognitive, and Learning
> Abilities".
> 
> <mg>Since parsing is going the way of the Dodo, ignoring</mg>

For Section 508 (and for EN), for now though, it's still 
relevant/needed. But yes, pragmatically I'd say ignoring it makes sense .

> * 4.1.2 Name, role, value: similarly, I'm wondering why this SC is also
> flagged under "Limited Manipulation" and "Limited Language, Cognitive,
> and Learning Abilities". Is the assumption that users from these
> categories also often use assistive technology, which will be affected
> by this?
> 
> <mg>That would be my expectations. “user agents, including assistive 
> technologies” is part of the normative text. See also Benefit 
> statement.</mg>

Hoping this assumption will be clarified a bit in future versions of 
these sorts of mapping documents.

P
-- 
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 28 February 2023 12:52:38 UTC