For the fifth year running, the periodic roundup of things that I enjoyed in 2021. Might not be 10 in the end…

1. Reading. I made a conscious effort and created the environment to read more books. 5 times more than in 2020, according to Goodreads.
2. Listening. Sonos, Airpods Pro, the in-car entertainment system and more recently, the Sony wh-1000xm4 headphones are great (Sony – probably the only company where engineers get to name the products)
3. Learning more about aviation (from Admiral_Cloudberg, among others) and space
4. Refereeing. A bit ironic, considering my take on non-human football referees 🙂
5. Sticking to a routine. 662 days and counting…
6. Viewing my pictures on the Google Nest Hub.
7. Not worrying too much that there are not 10 things in this list…

1. Accessibility is not only about screen readers and keyboard users. It’s about a system being accessible by anyone, from everywhere:
– if it’s too slow, it won’t load on poor connections
– if it only works in certain configurations (i.e. browsers), it won’t be accessible to everybody
– if the content it’s poorly written, too complex or difficult to be read then it’s not accessible

2. The impairment can be temporary (broken arm, eye surgery, etc) or situational (driving, party, theater). In my experience, I also found users that didn’t even know they had an impairment: they had a form of color vision deficiency (just like I do 🙂 ).

3. There is no drawback if you design with accessibility in mind (designing for the extremes). The non-disabled users will also benefit from this approach.

4. Add accessibility as a requirement early in the design. Think inclusive!

5. Challenge your team to use the system:
– using a screen reader
– without their hands
– on a browser without JavaScript
– from a poor connection (ex. Chrome Dev Tools can simulate this)

Resources:
Manuel Matuzović: My Accessibility Journey: What I’ve Learned So Far
W3C: Diversity of Web Users – How People with Disabilities Use the Web
Inclusive: A Microsoft design toolkit

Image source: https://medium.com/valtech-design/inclusive-design-dd4e03f82094

Content Security Policy (CSP)

The modern browsers are able to interpret the Content-Security-Policy HTTP header that defines which dynamic assets are allowed to load on a given website. Alternatively, the CSP content can be sent using meta HTML tags.

Example:

// allow everything but only from the same origin:
default-src 'self'; 
// allow JS but only from example.eu and from the same origin:
script-src 'self' https://example.eu/myapp; 
// allow XMLHttpRequests but only from example.eu and the same origin:
connect-src 'self' https://example.eu/myapp; 

You can find all the possible directives here and a tool that can generate your CSP header here.

The amazing thing about CSP is the Report-URI attribute, which will report the deviations from the policy to the specified URL:

Content-Security-Policy: default-src 'self'; 
report-uri http://reportcollector.example.com/collector.cgi 

One of the services collecting such reports is report-uri.com.

Subresource_Integrity (SRI)

SRI is a very simple and effective concept: the modern browsers load a given asset only if its hash matches the one defined in the ‘integrity’ attribute.

So instead of doing this:

<script src="//www.example.com/script.js" type="text/javascript"></script>;

it’s recommended to do this:

<script src="//www.example.com/script.js" type="text/javascript"
integrity="sha256-Abhisa/nS9WMne/YX+dqiFINl+JiE15MCWvASJvVtIk="
crossorigin="anonymous"></script>;

or even better, link each version of the remote asset with its own URL and hash:

<script src="//www.example.com/1.0.1/script.js" type="text/javascript"
integrity="sha256-Cng8gUe98XCqh5hc8nAM3y5I1iQHBjzOl8X3/iAd4jE=" 
crossorigin="anonymous"></script>

Cross-Origin Resource Sharing (CORS)

Problem:
– a script on client.com wants to access some data from server.com (ex. XMLHttpRequest)
– by default, the same-origin browser policy blocks this request

Solution:
– but by adding some special response headers, server.com can allow the script client.com to access the data.

The modern browsers have implemented a mechanism allowing scripts (like XMLHTTPRequest) to make cross-domain requests. This is Cross-Origin Resource Sharing and it uses a relatively less used HTTP request method (OPTIONS) plus several response headers (Access-Control-Request-Method, Access-Control-Request-Headers, etc)

Resources from Mozilla Development Network (MDN):

Glossary: CSP, SRI, CORS

Technical details: CSP, SRI, CORS

Context

Over the weekend, hackers injected thousands of websites—including UK and US government sites—with code that hijacked visitors’ computers to mine cryptocurrency.

The attack, noticed on Sunday by security researcher Scott Helme, was pulled off by compromising a single plugin that was used by all of the affected sites: Browsealoud, a reputable suite of accessibility and translation tools. According to Helme, the plugin was edited by attackers to embed a script that uses a site visitor’s computer to do the complex math that generates new digital coins (in this case, Monero). This process, known as “mining,” can slow down the victim’s computer.

The attack loaded malicious Javascript onto visitors’ computers. The hackers behind the attack chose to mine cryptocurrency, but they had the power to do almost whatever they wanted.
Cryptocurrency Mining Hack That Compromised Thousands of Sites ‘Could Have Been a Catastrophe’

Scott Helme: Protect your site from Cryptojacking with CSP + SRI
Troy Hunt: Trust in Third Party Libraries