- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 28 Feb 2023 12:52:22 +0000
- To: w3c-wai-ig@w3.org
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