- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sat, 11 May 2019 10:05:11 +0100
- To: w3c-wai-ig@w3.org
On 11/05/2019 03:52, Adam Cooper wrote: > Hi Patrick, > > I am interested in the notion of a 'hard' versus what is presumably a 'soft' failure of this or that success criterion ... are there any heuristics or general principles that you apply to arrive at one or the other? > > In my experience, recommendations of any sort rarely make the cut when decisions about what to fix are being made (though I do operate in a very compliance-driven context) This is a very subjective "gut feeling" categorisation I tend to use. While yes, WCAG SCs either pass or fail in a very binary way, there are situations where something "just barely" fails (think for instance a color contrast of 4.494:1 for a particular text foreground/background combination - yes, it fails the normative 4.5:1, but realistically it's really not the case that that 0.06 shortfall in ratio will make the difference between "user can not distinguish the text at 4.494:1, but as soon as we bumped it to exactly 4.5:1 it was like a veil was lifted from their monitor and they could properly see it"). Those would be "soft" fails in my view... "Hard" fails would be things that are very unambiguously no-nos per spec. Say a site that simply has NO keyboard interaction available at all, where the entire thing only works with a mouse. That's a clear-cut HARD fail of 2.1.1. Then there's probably things that aren't failures per WCAG - where WCAG doesn't explicitly say "you must do this / you can't do that", but they're just not good or go against the broader principle behind a guideline, without actually contravening any normative wording in an SC. Arguably, even things that are mentioned in an understanding document aren't necessarily "hard" failures, if they're more of a loose interpretation of the normative language itself, since understanding documents are only informative. A lawyery type person may well be able to argue that only the raw normative SC text counts, and that understanding documents may not always be correct and represent more of an opinion. In those cases, we're possibly more in the territory of best practice recommendation, a la "while normatively this passes, we'd strongly recommend you don't do it this way..." And in terms of making recommendations/writing reports for clients, in our own reports we generally indicate a (subjective) measure of severity for failures (that hard/soft kind of distinction, though we use low/medium/high). Although we clarify that any failure IS a failure, and that normatively they are failing a particular SC, we do provide them a rough idea of "well, THIS particular failure is pretty fundamental and catastrophic for this particular group of users, so it should really be fixed as soon as possible" versus "this particular issue is more of an annoyance...nobody dies because of this thing you did. yes, don't get me wrong, it's still a failure of that particular SC, but i'd prioritize the showstoppers over this one". Of course, once you then get into best practice recommendations, as soon as a client hears "this is not actually a failure of WCAG, but..." they often just ignore the rest of the sentence ... though some customers do care, thankfully... P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Saturday, 11 May 2019 09:05:41 UTC