larlet-fr-david/david/stream/2015/12/13/index.md

title: Couper la moutarde

> Someone once suggested to me that a client’s website should include two states. The first state would be the *ideal* experience, with low color contrast, light font weights and no differentiation between links and text. It would be the default. The second state would be presented in whatever way was necessary to meet accessibility standards. Users would have to opt out of the default state via a toggle if it wasn’t meeting their needs. A sort of first-class, upper deck cabin equivalent of graceful degradation. That this would divide the user base was irrelevant, as the aesthetics of the brand were absolute.
>
> It may seem like an unusual anecdote, but it isn’t uncommon to see this thinking in our industry. Again and again, we place the burden of responsibility to participate in a usable experience on others. We view accessibility and good design as mutually exclusive. Taking for granted what users will tolerate is usually the forte of monopolistic services, but increasingly we apply the same arrogance to our new products and services.
> 
> <cite>*[Designing with Contrast](https://24ways.org/2015/designing-with-contrast/)* ([cache](/david/cache/ac703f60904aa9229b5ef1c2d3bb541e/))</cite>

C’est la raison pour laquelle l’approche qui consiste à [couper la moutarde](http://sixtwothree.org/posts/cutting-the-mustard-revisited) ([cache](/david/cache/2d8045c2482f4bdee26d3d89557aaccf/)) me laisse un goût amer, scinder ainsi la population des visiteurs entre riches et pauvres (ou tout autre euphémisme de type *éduqué numériquement*) est brutal et ne correspond pas à la réalité du web qui est loin d’être binaire. C’est pourtant un compromis alléchant qui donne bonne conscience aux développeurs mais la frontière est mince entre *amélioration progressive* et *discrimination radicale*. Cela me rappelle la vieille dualité entre mobile et desktop, **il serait peut-être temps de définir collectivement quels sont les breakpoints d’amélioration acceptables comme on a pu le faire avec le responsive.** À chacun ensuite d’appliquer ceux qui sont pertinents pour son audience, son équipe et son but lorsqu’il produit des sites web.

> When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitrary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web *app*. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”
>
> We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job. We want the user to think about The Website—to sympathize with *us*—over their reason for being there. We’re making them sit through a lecture about furniture design every time they try to sit down in a chair.
>
> When we prize our own convenience over craft, we’re building a web for us, the developers. We’re building a web that’s easy to assemble but lousy to use.
>
> That’s not what the web is to me, though—that’s not what this job is, to me. The meaning I take from this gig doesn’t come from getting a div to show up in the right place. It comes from knowing that working just a little harder can mean that entire populations just setting foot on the web for the first time will be able to tap into the collected knowledge of the whole of mankind.
>
> <cite>*[Smaller, Faster Websites](https://bocoup.com/weblog/smaller-faster-websites)* ([cache](/david/cache/5d9f9a594bd1e323e38854f42e1e1238/))</cite>