Resources

Week 1

Lecture 1

Everyone has JavaScript, right?

• “All your users are non-JS while they're downloading your JS” — Jake Archibald
• DID THE HTTP REQUEST FOR THE JAVASCRIPT COMPLETE?
• People who switch off JS.
• Addons / plugins block loading

Progressive Enhancement is still important

Progressive enhancement has never been about users who've turned JavaScript off, or least it wasn't for me.

When an escalator fails, it becomes stairs. We should be building escalators, not elevators. Given the diversity of user agents, your JS failing isn't an edge case.

Feature detect to to decide if scripts should be loaded. "Cuts the mustard"

Code running on the client is more of a testing effort due to the diversity of interpreter vendors and versions.

Here's how most pages load:

• HTML downloads
• CSS downloads
• CSS fetches additional assets
• JS downloads
• JS executes
• JS fetches additional assets
• JS updates DOM

There's a perception that progressive enhancement means building everything on the server then building it again, like for like, on the client.

The more you take over from the browser, the more complex yet expected browser behaviour you have to reimplement in JavaScript.

I Turned Off JavaScript for a Whole Week and It Was Glorious

THERE’S ANOTHER WEB out there, a better web hiding just below the surface. When you visit a website, the JavaScript programs embedded on that site run automatically.

When JavaScript turned off, most things just work and in many cases nearly better. Cookies still work if you turn of JavaScript.

Turning off JavaScript limits your exposure to exploits, and reduces the number of ways that third parties can vacuum up your data. he Free Software Foundation doesn’t want to do away with JavaScript, but rather wants to give users more transparency and control over the code that runs on their computer.

But the experiment left me longing for more control over what actually runs inside my browser. It showed me how unnecessary the clutter that’s been built up around the web really is, and just how easy it is to make it all go away.

Lecture 2

The Accessibility Mindset

Accessibility is often characterized as additional work, hard to learn and only affecting a small number of people. But it isn’t particularly harder to learn than those other skills.

Accessibility has a very close relationship with usability, and advancements in accessibility often yield improvements in the usability of a website.

Beyond the bare minimum hat it can’t do is measure how well you met them. Wrap label aroudn input to make gutter clickable. You can also set the label to display: block. The result enhances the usability of your form element tremendously for people with lower dexterity, using a voice mouse, or using touch interfaces.

Providing always visible text is an alternative that can work well if you have the space. It also helps users understand the meaning of the icons. Clever usability enhancements don’t stop at a technical implementation level.

Conclusion You can only produce a web project with long-lasting accessibility if accessibility is not an afterthought. Users often don’t notice when those fundamental aspects of good website design and development are done right. But they’ll always know when they are implemented poorly.

A BBC iPlayer Case Study

Not long after I started working at the BBC, I fielded a complaint from a screen reader user who was having trouble finding a favorite show. It was clear that, while the website had been built with accessibility in mind, it hadn’t been designed with accessibility in mind and this is where the issues originated.

The Challenge
At the BBC, a number of internal standards and guidelines are in place that teams are required to follow when delivering accessible website and mobile applications. There is also a strong culture of accessibility; the BBC is a publicly funded organization, and accessibility is considered central to its remit.

Part of the issue is that standards and guidelines tend to focus more on code than design. Most of the thinking and requirements should be considered up front so that poor accessibility isn’t designed in

Give Users choice
Never assume that just because a user can access content one way that they want to access content in that one way.

Put users in control
Never taking control away from the user is essential. Pinch zoom for example.

Design with familiarity in mind
There needs to be a balance between the new and the familiar. While structure is typically viewed as a responsibility of developers, it needs to be decided before designs are signed off in order to prevent poor structure getting coded in. Reinforce a logical heading structure within the code.

Prioritize features that add value
Accessibility at the BBC is not just about meeting code, content and design requirements, but also about incorporating helpful features that add value for all users. When we incorporate features to help users with specific disabilities, everyone gains access to a richer and easier experience.

Using one’s device of choice, whether it be iOS or Android, is much easier for a disabled user than using a remote control and a potentially inaccessible TV interface.

Guidelines

• Color contrast, color, content order, structure, containers, duplicate links, touch raget, spacing, zoom, actionable elements.

All of the thinking around inclusive design that comes from product owners, UX practitioners and designers needs to be captured and communicated to developers and engineers. At the BBC, we are moving to a model where designs need to be annotated for accessibility.

The UX practitioner doesn’t need an in-depth knowledge of code, but rather an understanding of the hierarchy of data within a page. Equally, indicating the logical order of content helps developers to code content in the right sequence.

Summary Listening to users and actively including their feedback, along with adhering to organizational standards and guidelines, are essential.

Week 2

Lecture 1

Writing forward compatible website

JS

Prefix all global variable acces in onfoo attributes with 'window'.
What this means is that any time you access a global variable in an event handler content attribute, including calling any function declared globally, you can end up with a name collision if a specification adds a new DOM property to elements or documents which has the same name as your function or variable, and a browser implements it. If that happens, then suddenly your function stops being called.

Don't concatenate scripts you don't control
So appending a script that depends on non-strict-mode behavior to a strict-mode script will cause things to break.

Sniffing Sniff for specific features
If you plan to use some feature, use object-detection to sniff for that exact feature, if possible. Don't assume that browsers with support for a given DOM feature must also have some other, especially nonstandard, DOM feature.

Don't UA-sniff

Testing Test with all major engines
Firefox, chrome safari, opera and IE. Sometimes browsers implement a given feature slightly differently.

Browser-specific features and prefixes Don't target hacks at corrent or future version of browsers.
Avoid depending on cutting-edge nonstandard features
Even if the feature is prefixed. Prefixed are to experiment with and aren't meant to be deployed. Test your fallback paths.

Don't use vendor-prefixed features except to target old buggy versions Always yse the unprefixed version when available, but for support use old prefixes. Unprefixed one needs to come last.

Code hygiene Avouid missing>
Missing them can lead to unexpectes situations due to a following tag name being treated as an attribute.

@supports

@supports gives CSS the ability to perform a feature query. not operator and operator or operator

Progressive enhancement and JavaScript failure

Progressive enhancement is about making web sites more robust and providing a good experience to every user. progressive enhancement “is about asking ‘if’ a lot.

No fallback on JavaScript failure Avery’s most important point is that progressive enhancement does not address the fallback to the simpler version in case the enhanced JavaScript version fails for some reason.

If JavaScript fails for reasons not anticipated, usually people are stuck and there are no stairs.

Updating JavaScript The main goals of Unobtrusive JavaScript were to provide a functional user interface when JavaScript is not available or modern JavaScript APIs are not supported.

Begin JavaScript JavaScript logic is typically a one-way street. There’s no safe and easy way of turning around in the middle of it. We’re terribly optimistic here, disabling the browser’s standard behavior, assuming our JavaScript will take over, fetch and display the results.

If you’re familiar with JavaScript and the hostile environment named browser, you’ve probably experienced that JavaScript may fail without throwing exceptions. ti