• I helped Bulb make their new, accessible design system
• Inclusive Components went from blog to book
• I created a customizable generative art gallery with SVG and Vue
• I learned lots about web components and created a prototyping tool
• I gave my third Fronteers conference talk
• I wrote and produced my first instructional videos, on CSS custom properties and CSS shapes
• I wrote about the many JavaScript arrow functions
• I spoke at my second London Accessibility meetup
• I started working with the BBC to help them rewrite their front-end design patterns
• I gave the last keynote at the wonderful a11yTO conference
• I started a conversation about full stack development, sexism, and capitalism
• I went bowling with some Syrian refugees
• I ran my first workshops, in The Hague and Toronto
• I had a lot of dark and hopeless days, was visited by the memories of past failures and degradations, and cried in the shower a lot
• Some stuff I can’t remember

It’s not that the computer scientists get to do all the code; it’s that they get to do architecture while I do communication, form, and interaction. We all code, because we work on the web, but we code in different ways to achieve different and complementary ends.

But that’s not so obvious to someone who doesn’t code at all: it’s easy to think coders are people who do all the code you’re not doing — because, to the untrained eye, all code is the same.

This misconception has unfortunate consequences, exacerbated by the non-coder often being the one who gets to choose and hire technical staff. The doctrine of capitalism dictates you should squeeze the most value out of the fewest resources. That’s how you make a profit. If you can find wage slaves willing to do All The Codez™, then you can significantly diminish your biggest overhead: people.

And so the Full Stack Developer emerges in the market, like an Uruk-hai emerging from its grimy placenta: stronger, better, problematic.

Problematic how? Well, HTML, CSS, JavaScript, Python, C#, and SQL may all be code, but they’re really quite different kinds of code and are suited to different kinds of people. Just taking the frontend technologies: HTML, a metalanguage, is closely associated with language, narrative and meaning: the realm of the writer. CSS codifies form, the purview of the typographer and graphic artist, while JavaScript (client-side in this case, but the real™ programming language to a computer scientist) deals in things like data transmission and events.

This is all to say that, if you put someone in charge of all of these things, it’s highly likely they are going to be much weaker in some areas than others (I’m identifying a trend here; there’s no need to comment with “but I can do all the things”, thank you). Worse: they’ll tend to have little interest in improving in areas with which they don’t identify or for which they aren’t rewarded. In my experience, men especially earn kudos for their knowledge of JavaScript, but little from CSS skills. CSS, which makes things look ‘pretty’, is considered feminine (don’t tell that to a peacock).

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well. This has two adverse effects:

1. Poor quality code
2. A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”

As an inclusive design consultant, one of the most glaring issues with making Full Stack Developers the gatekeepers of all-things-code is the pitiful quality of the HTML output. Most come from a computer science background, and document structure is simply not taught alongside control structure. It’s not their competency, but we still make it their job.

To a ‘classical’ computer scientist, CSS can be quite elusive. Features like the cascade just don’t feel right. To make CSS easier to write and manage, it becomes subsumed by something more familiar, hence CSS-in-JS.

CSS-in-JS is often characterized as a solution (by practitioners) or a problem (by naysayers) in technical terms. I don’t think it makes the actual CSS intrinsically any better or worse — it’s just a different way to write it. But that’s not to say it doesn’t pose a grave cultural issue:

Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

I recently worked with an organization where there were dozens of Full Stack Developers and no Frontend Developers. We had a website to build and nobody understood Flexbox, except me. Of course I was happy to help, but I had to learn React on the job to put the work in place. Fortunately I picked it up quite quickly, but the next CSS expert may not have done. The value you want from a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.

To conclude, here are a few things I think we need to address:

1. We need to identify exploitation. While there are some gleeful Full Stack Developers, many are computer scientists given too many responsibilities, and over things for which they are not willing or qualified to be held accountable.
2. We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.
3. We need to revisit the separation of concerns principle. We simple can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.
4. Most of all, we need to educate people who don’t code at all just how many different things different types of code can do, and how different each is to understand and write. Hopefully, this way, more of us will be writing the kind of code that suits us best, and not spending our time anxious and demoralized because we don’t know what we’re doing. That’s not to say that if you do take to JS, CSS, HTML, SQL, and C# you shouldn’t be writing all of them if you‘d like to and you have enough time!

Those familiar with the web platform will be well-versed in its two complementary technologies: HTML for documents and their structure, and JavaScript for interaction and styling.

For as long as anyone can remember, styling documents — affecting their appearance — has been facilitated via the JavaScript style property, which is exposed for any supporting DOM node.

node.style.color = 'red';

Before the advent of this styling API, HTML authors had to write style attributes into the DOM manually, impeding the editorial process.

Combined with JavaScript’s node selection engine, we are able to style multiple elements simultaneously. In the following example, all p nodes are styled with the red text color.

const nodes = document.querySelectorAll('p');
Array.prototype.forEach.call(nodes, node => {
  node.style.color = 'red';
});

One of the great things about this selector engine is it allows one to target different elements simultaneously, by providing a comma-separated list.

const nodes = document.querySelectorAll('p, li, dd');

What’s less straightforward is attaching multiple styles to any one node. The following approach quickly becomes verbose.

node.style.color = 'red';
node.style.backgroundColor = 'black';
node.style.padding = '1rem';
// etc.

The only standardized alternative is to use the cssText property:

node.style.cssText = 'color: red; background-color: black; padding: 1rem;';

Managing multiple styles as a single string is problematic. It makes it difficult to update, remove, or replace individual styles at a later point in time.

For this reason, authors have invented ways to manage styling information in objects, often by manipulating the Element interface’s prototype.

Element.prototype.styles = function(attrs) {
  Object.keys(attrs).forEach(attr => {
    this.style[attr] = attrs[attr];
  });
}

Adding styles to a node is now possible like so:

node.styles({
  'color': 'red',
  'backgroundColor': 'black',
  'padding': '1rem'
});

This assignment approach tends to get used a lot throughout an application and its lifecycle. It’s infamously difficult to know where to put all this stuff, or how to clearly separate it from the interaction scripting that is JavaScript’s other responsibility.

But there’s another, more fundamental, problem: these style properties are not reactive. For example, let’s say I’ve set some styles for disabled buttons:

const disableds = document.querySelectorAll('[disabled]');
Array.prototype.forEach.call(disableds, disabled => {
  disabled.styles({
    'opacity': '0.5',
    'cursor': 'not-allowed'
  });
});

These styles only apply to disabled buttons that are already in the DOM. Any disabled buttons added to the DOM or — more likely—buttons that acquire the disabled property/attribute, will not automatically adopt the appropriate styling.

button.disabled = true;
button.style // nothing new here

It is possible to listen for the attribute change and react to it using mutationObserver:

const button = document.querySelector('button');
var config = { attributes: true }
var callback = function(mutationsList) {
  for(var mutation of mutationsList) {
    if (mutation.type == 'attributes') {
      if (button.disabled) { 
        button.styles({
          'opacity': '0.5',
          'cursor': 'not-allowed'
        });
      }
    }
  }
}
var observer = new MutationObserver(callback);
observer.observe(button, config);

I think we can agree this is quite a lot of code, especially since it only makes one instance of one type of element reactive to one type of attribute change. It also only changes the styling in one direction: we’d have to handle reverting the styles when the disabled property is removed. Not easy, since we don’t know the initial values for opacity or cursor.

As much as I like JavaScript, I don’t think it’s very well designed when it comes to styling tasks. It is, after all, a procedural and event-based language, whereas style is just something you have or you don’t.

We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS.

CSS

CSS is a declarative subset of JavaScript, optimized for styling tasks. A CSS file takes the .css extension and, importantly, is parsed completely separately to standard JavaScript files. With CSS it’s finally possible to separate style from behavior. You can brand your applications without having to touch your business logic!

Syntactic sugar

One of the first things you’ll notice is the cleaner syntax, which fans of CoffeeScript will appreciate:

[disabled] {
  opacity: 0.5;
  cursor: not-allowed;
}

The object-like structure remains, but you no longer have to explicitly call upon querySelectorAll to iterate over DOM nodes. The iteration is taken care of internally instead, making it more performant too.

The above example affects all DOM nodes with the disabled attribute automatically. Better yet: any new buttons adopting the disabled property will immediately adopt the associated styles. Reactive out of the box!

The cascade

CSS stands for Cascading Style Sheets. The cascading part is perhaps its best feature. Consider the following CSS.

button {
  background-color: blue;
  cursor: pointer;
}
[disabled] {
  cursor: not-allowed;
}

The styles for the [disabled] ‘block’ come after the button block in the style sheet. Any styles declared in the [disabled] block with the same keys (property names) as those in the preceding button block become overrides. The upshot is that adding the disabled attribute/property to a button only updates pertinent styles. In the above example, cursor is updated but background-color remains the same. It’s a kind of filtering system.

In addition, where the disabled attribute/property is removed, the default styles are automatically reinstated — because now the node only matches the button block further up the cascade. No need to ‘remember’ which styles have been applied and under which conditions.

Resilience

When styling with JavaScript, any unrecognized style properties or syntax mistakes will cease the parsing of the script. Any ensuing styles or interactions will simply be dropped en masse and your whole application will fall over.

CSS is more robust. In most cases, an unrecognized property or a syntax mistake will only cause the single, erroneous declaration (property/value pair) to be dropped.

This innovation acknowledges that different browsers support different styling properties, and that individual styles are not mission critical. The resilience of CSS means more users get access to a functional interface.

Conclusion

A good sign that a technology is not fit for purpose is how much we have to rely on workarounds and best practices to get by. Another sign is just how much code we have to write in order to get simple things done. When it comes to styling, JavaScript is that technology.

CSS solves JavaScript’s styling problems, and elegantly. The question is: are you willing to embrace the change, or are you married to an inferior methodology?

For more information on CSS and tips on getting up and running, read this primer.

It’s attached to a non-interactive element

It’s not a tooltip if there’s no tool (control, button, whatever). What you’re really doing is just hiding content away. Why?

It’s attached to a non-interactive element that’s focusable

So, at some point, you realize that your faux-tooltip (see above) only works on hover, meaning keyboard users don’t have access to it. Accordingly, you add tabindex="0" to it or turn it into a <button>.

You’ve played yourself. Non-interactive elements (elements that do nothing when you click them) should not be focusable, as per Focus Order, 2.4.3.

Even if you consider the showing of the tooltip an interactive ‘action’, it happening on focus makes little sense, especially to unsighted screen reader users who won’t know anything has happened.

It doesn’t work by touch

Your tooltip is a tip for an actual tool: good. But it doesn’t work by touch because tapping the tool/button/whatever activates it. If the user’s lucky, they may see the tooltip briefly before the button’s action takes place. By then, it’s too late.

Yes, this means that most tooltips are just not viable components in 2018. Solve the problem differently.

It does nothing for AT users

Okay, you’ve decided to make the tooltip click-activated because that works by touch. Of course, now the button can only show a tooltip and do nothing else. Not a problem, if that’s all it’s for.

But! You’ve also used aria-labelledby or aria-describedby so that screen reader users have access to the tooltip message from the button. Great, but now clicking the button doesn’t actually do anything as far as they can tell.

The tooltip contains interactive content

You’re thinking of dialogs. Use a dialog.

You probably don’t need to use a tooltip, but if you do I wrote this to help you go about it in an accessible way.

It’s amazing how many sites don’t do this. I know, because as an accessibility specialist I have to look out for it. If it’s not there, there are certain implications for screen readers and their voice profiles.

Anyway, services like Google’s do most of the heavy lifting by looking for strings and simply translating them. Not as good as a manual translation by a bilingual, human speaker, but surprisingly okay.

The only trouble comes with attributes, and determining which provide strings for users, and which programmatic tokens. While you wouldn’t want aria-pressed="true" to be translated to aria-pressed="vrai", strings intended for human consumption like the value of an aria-label should be covered.

Unfortunately, unlike longstanding attributes marked for assistive technology consumption (alt and title to name a couple), aria-label is ignored by Google’s translator. MS Translate has the same issue, I’m told.

So yeah, aria-label kind of refuses to speak other languages (but, in fairness, it’s not really aria-label‘s fault).

Here are some test cases

• Using alt and title for a submit button/image
• Using aria-label for a submit button

(English should be listed as a supported language in Chrome, but not French, for these to work.)

Workarounds

✖️ Not recommended

So, you could use JavaScript to dynamically assign the aria-label based on the page’s lang…

const labels = {
  en: 'Submit',
  fr: 'Soumettre',
  es: 'Enviar',
  de: 'Einreichen'
};

const lang = document.documentElement.lang;

const submit = document.querySelector('[type="submit"]');

submit.setAttribute('aria-label', labels[lang]);

Urgh. That could quickly get unmaintainable when managing a lot of ARIA labels. One thing it does have going for it, though, is more control over the specific translation, so it might be a good way to override automatic translation.

✔️ Recommended

Use aria-labelledby! It refers to an element (which can be hidden if you like) containing a text node, which we know gets translated.

<span id="submit-label" hidden>Submit</span>
<button type="submit" aria-labelledby="submit-label">→</button>

See how the #submit-label element is hidden. This means it won’t be encountered independently of the button by screen readers but, because of the explicit association, it still announces when the button is focused. Good.

✔️✔️✔️ More Recommended

That last approach is a bit complex and contrived. Why not just have a visually hidden <span> inside the button?

<button type="submit">
  <span class="visually-hidden">Submit</span>
  <span aria-hidden="true">→</span>
</button>

Note the aria-hidden. Now that an ARIA label isn’t there to override the “→” text node, this symbol would be read out in screen readers (“right arrow”). Using aria-hidden puts a stop to that.

✔️✔️✔️✔️✔️✔️ GALAXY BRAIN RECOMMENDED

Just use some fucking text. Text that people can see and read and hear in their screen readers all at once. Fucking arrows.

• Have perfect eyesight
• Have excellent motor control and coordination
• Speak English as a first language
• Find reading and processing complex information easy
• Never get tired
• Have as much free time as you wish
• Live somewhere with access to super fast internet
• Can afford super fast internet
• Have a top-of-the-range smartphone or computer
• Have perfect hearing
• Never suffer any injuries or illnesses, even temporarily
• Never feel the effects of pain
• Are a member of a preferred social/cultural group

then you may not benefit from inclusive design.

A jug.

I say threw, but it was more a sort of lacklustre roll — the kind of half-baked act of defiance one might expect to be inspired by Linkin fucking Park.

Linkin Park have always been soulless, gutless, wet shit. They are no more a hard-rock-and-metal band than Avril Lavigne. At least Avril (“Avy”, I call her) was able to elicit hatred. So why the sudden consternation about their new record, “One More Light”?

Don’t get me wrong, it is bilge. I mean, it has a song promisingly titled “Battle Symphony” but which sounds like Katy Perry gently pity-wanking an elderly Jonas brother. But what did anyone expect? When you were listening to all the other Linkin Park records what were you thinking? “2002 projections show that this band of whinging, charmless gimps will be the new Motörhead by 2017.”

I’m being disingenuous. I know perfectly well why fans are hypoglycemically lobbing jugs at Linkin Park, and it’s all about the broken pact. With this record, Linkin Park have welched. From the outset the deal was that they’d ship a few overproduced “heavy” guitars. That way you could fill your boots with insipid whining but pretend you were listening to actual rock and roll music.

Distorted guitars can’t make music cool, punk, or rebellious on their own and Linkin Park are testament to that. But they seem to make it easier to believe you’re not listening to the same generic waffle as everyone else, if that’s what you need to believe.

Now all the guitars are gone and you’re left with the same beige effluent there always was. You either like it or you don’t and, if you don’t, you wasted the last 15 years not listening to Nasum.

Just the other day, I went to code a submit button for a form. Should be pretty straightforward. Well how come this is what I wrote, then?

<table>
  <td>
    <a class="submit">
      <img src="submit-image.bmp">
    </a>
  </td>
</table>

I’ve had complaints from users saying they “can’t use this shit” and mean developer “friends” have pointed and laughed at me, like it’s some sort of failing on my part.

But let’s look at the facts:

1. I have a degree in computer science
2. I literally probably have a really high IQ. That stands to reason.
3. I live in San Francisco
4. That’s where Silicon Valley is. Ever heard of it??

I may have majored in computer science, but I minored in rationalist scientific enquiry. I say minored; it was more of a hobby. Anyway, given the FACTS provided above, if I see myself writing shit code I can only draw one logical conclusion:

It’s not me who’s stupid, it’s you. You stupidly designed the stupid thing I’m trying to use stupidly and it’s all your fault. Stupid HTML standardista stupid bum faces.

I rest my case.

But if that isn’t enough to convince you that HTML is trying to make me look bad, wait until you see just how poorly HTML deals with basic arithmetic! Consider the following code example:

<p> + <i>

Which of the following do you think the above code evaluates as? The answer may surprise you.

1. <p><i>
2. <pi>
3. π
4. IT JUST WRITES IT OUT THE SAME THEN COMPLAINS AT ME ABOUT MISSING CLOSING TAGS WHATEVER THEY ARE??1!!?1!

I can do basic arithmetic, HTML. Why can’t you? Oh, you’re a “markup language” are you? Well bully for you. I didn’t learn about HTML in my Ivy League university of choice, so how could I know that?

Fine, whatever. When there’s an international standard for formatting and transmitting digital information available, I’LL USE IT TO FUCKING WELL LOOK UP WHAT HTML IS, HOW ABOUT THAT?

Idea for this article from @petervangrieken.

If you’re struggling with the finer points of writing accessible markup, I have a new blog called Inclusive Components which explores the inclusive design of web interfaces.

Victims included those with Down syndrome, cerebral palsy, and various localized deformities. A district judge, Lothar Kreyssig, wrote to protest against the programme. The minister of justice, Franz Gürtner, replied: “If you cannot recognize the will of the Führer as a source of law, then you cannot remain a judge.”

Kreyssig was deposed. In towns hosting killing centers, residents reported the persistent smell of burnt human hair.

The Nazis believed disabled people were better off dead. I’ll leave you to decide whether they felt it was better for the ‘patients’, better for the Nazi vision of society from which they were being expunged, or better for both. In any case, the Nazis saw no value in these people.

So it was under German fascism. Since the 40s, fascists operating within ostensible democracies have had to find ways to obfuscate their intentions, including their disableist ones. And I don’t just mean the ability to hide behind digitally transmitted pictures of cartoon frogs.

Of course there are obvious displays of ignorance, like Donald Trump referring to deaf actress Marlee Matlin as “retarded”, or Betsy DeVos having seemingly no understanding of The Individuals With Disabilities Education Act. But it runs much deeper than this.

Attorney General appointee, Jeff Sessions is on record saying he believes protections helping to integrate disabled children have accelerated the decline of “civility and discipline” in mainstream classrooms. The notion that groups which include disabled people are less civilized as a result is particularly striking for its fascistic overtones.

That’s not to say Sessions outright proposes the eradication of the disabled from society, Nazi-style. But, then again, he wouldn’t have to. There’s a more passive way of killing off those deemed surplus, and that’s by letting them die neoliberalism-style. That’s precisely what the slashing of Medicaid, the trashing of the ACA, the segregation and disenfranchisement of the disabled in education, and the diminishing of workplace rights would mean.

Of course, to get away with this you need an alibi. And that alibi comes in the form of a particular brand of freedom. According to the Milton Friedman school of free market economics, true deregulation will lead to the eradication of discrimination. Why? Because there’s money to be made by and from all types of people. Pure market forces, we’re told, are “color blind”. Ergo, cutting state support for the vulnerable is actually good for them!

There’s just one problem with this ideology: It’s a trap. The rich establishment don’t need intervention and support from the state. At the point that it is removed, they are placed at an increased advantage, happily able to exploit the market and those now placed at its mercy.

The market has no mercy. That’s the point. But like the Christofascist God for which it makes a telling analogue, it cannot be questioned. To tamper with market forces means to defy its will. Accordingly, when the Americans With Disabilities Act (ADA) was first discussed at the start of the 1990s, it was met with opposition. Business leaders argued it represented a reregulation of the labor market, which ultimately would lead to greater opportunities for discrimination.

This was all completely disingenuous, of course. These people don’t really believe in God or the free market. They want to be free to discriminate as they please, for greater personal gain, and for everyone else to believe they are entitled to do so guilt free. They are interested in being Gods.

One way this is achieved is by erasing the meaning of being disabled. It is for good reason that many object to the term “differently abled”: Differently abled implies equally abled, and equally abled means you can weather the “mysterious ways” of the market just as well as me. You don’t need support or special treatment.

This works as well for mental health as for physical: As a depressive, I’m told it is my choice to feel that way; I’m just wallowing. There’s a gleeful orgy of futility happening down at the marketplace, and I don’t want to get on the bus. It’s my own fault I’m missing out.

Another way of leveraging the concept of the market to defer guilt is through the notion of niche. Friedman’s model imagines greater prosperity for all, but that’s not to say the market would become homogenous. There would still be sectors and segments; varieties of business and product.

By characterizing disability as a discrete ‘target’ group, the aim is to excuse the creation of products and services which do not cater for disability. “Oh I’m not making things for disabled people. But I’m sure someone else is, don’t worry. Such-and-such law of economics states it must be so.”

Disability does not work that way, though. It isn’t a discrete community or field of interest. It is complex, multifaceted and pervades all kinds of cultural identity through race, socio-economic level, gender identity, and faith. If you create an inaccessible product or service, you are almost guaranteed to be disenfranchising someone, including your future self.

It is because disability is such a broad category of human experience that it’s so easy to neglect. Even some of those trying to combat discrimination and bigotry have trouble grappling with disability rights as civil rights. It was, after all, amid concerns that the Women’s Marches did not originally include a clear statement on accessibility that the virtual march was conceived.

A few things to remember

Firstly, try not to snort at “armchair activists”. Some don’t have the choice. They’d like to march, but they simply can’t.

Secondly, be wary of people who insist on removing politics from conversation or company policy. The official position is that we live in a meritocracy, benevolently guided by market forces, so positive discrimination is not necessary. You’ll find that it is only the ones who are already well represented and paid that take this stance (remember the ‘trap’ I described previously).

It’s more passive and less transparent to discourage political discourse than it is to outright tell someone that their politics is not welcome. If someone tells you to “take the politics” out of what you’re doing, or to “stop making things political”, it’s not because anything benefits from being less political as such. It’s because they don’t want to make room for your politics in that space. That would mean taking some of theirs out. Well screw that; resist.

Thirdly, be aware that making accessible products and interfaces under a regime that regresses on disability rights is resistance. It goes against the prevailing ideology. Do it loudly and help others get up to speed. This is especially important when devising protests and related resources. When you’re inclusive, you reach more allies.

Finally, whether or not you believe it is right or sensible to punch a neo-nazi, remember that not everyone who might like to punch a neo-nazi has the physical strength, the dexterity, or even the appendage to do so. And some of these people would be first in line if they did, because they know fascists are the kind of cowards that pick on them first. Accordingly, whether you aim to do it literally or figuratively, punch a neo-nazi for someone who can’t.

I’m not convinced the far right will develop a sudden fondness for anyone with a better tan than them, doctors and scientists will be respected and revered for actually knowing a thing or two, or Mike Pence’s head will spontaneously fall off, exploding in a cloud of rainbow-colored sherbet.

What I’m doing

In the new year, I want to offer my services — at reduced rates * — to organizations who are doing good for society in the wake of neoliberalism and under the spectre of fascism; organizations who are trying to make things a bit better for ordinary and vulnerable people.

I’m only one person who can only make the tiniest difference and, hey, maybe I’m only doing this to quell my own guilt for having the privilege of being a white, male, english speaker. But anyway.

What I can offer

• Branding (styleguides — including typography, iconography etc. and associated documentation)
• Pattern libraries (catalogues of attractive and accessible interface components written in HTML, JS, and CSS)
• Prototyping
• Accessibility remediation (diagnosis and advice on fixing accessibility and usability issues in your existing interfaces)
• Copywriting and help with readability
• Fast, responsive websites
• Other stuff; just ask

I’m a web designer/developer with 10+ years experience. I have two books published on interface design with Smashing Magazine. The latest, Inclusive Design Patterns, was released just a month ago and is set to sell out before Christmas. I worked as a front-end developer for several years with Neontribe, helping to design and create applications for folks with disabilities and mental health concerns, as well as for educational projects. I currently work with The Paciello Group who offer expert accessibility guidance to large organizations, mostly in the US. I have spoken (including keynotes) at large conferences in The Netherlands, Sweden, Germany, Romania, and the UK on interface design and web accessibility.

Who I’m offering work to

• Charities and non-profits supporting the vulnerable, disabled, and ethnic minorities
• Campaign and legal organizations working to protect civil liberties and rights
• Organizations fighting racism
• Organizations representing and advocating for the LGBTQ community / communities
• Advocate organizations for the autistic community where autistic folks actually have an influence in the organization
• Feminist organizations and organizations supporting women’s reproductive rights
• Organizations offering free education services, especially in politics and critical thinking

One type of organization I will not work for is any organization that uses resources to promote religion. So, for example, I’d be delighted to support the Muslim community but not the spread of Islamic doctrine. Another example would be a Christian organization which includes proselytising in its activities. I am a humanist and want to work with people, including religious individuals, if the cause and focus is to help other human beings in need.

I work remotely and I tend to restrict long haul travel for the sake of mental wellbeing and productivity.

Is this you?

Are you someone working for any such described organization? Or do you know someone who is? I’m available by email: heydon@heydonworks.com.

* Negotiable. My standard corporate rate is not exorbitant already and I am prepared to offer between 33% and 50% reductions. Under some circumstances, free work may be applicable.

Is this you? Then you are not a coder. You are a designer who is skilled in coding.

But it is not a discrete profession or occupation.

We are not divided into designers and people who are not designers.

If someone says you don’t have the right background, you haven’t spoken to or listened to the right people, or you don’t have the appropriate skills or experience to be a designer? They are wrong.

If someone says particular skills — creative, discursive, technical — preclude you from being a designer and put you in a category outside of design? They are wrong.

Design is not in the mastery of any particular medium, skill, piece of software, style, or philosophy.

Websites, boats, guns, hats, buildings, events, fonts, and data schemas can all be designed or not designed. But it isn’t in hiring a designer that the crucial difference is made.

All design consultants can do is encourage you to design. And you should know enough to be doing it already.

Designing is deliberating; reasoning; justifying. It is joining up the dots.

Designing is what we’re doing when we’re not doing. It’s deciding what’s right to do, what the best way to do it is, for who, by who, for how long, and with what. Context, relationships, implications.

If you don’t do any of this, your work will be horrendous. If you hire someone else to do it for you, it will not be saved. You cannot add design.

If you care to think about your work as you work, then you are a designer.

Everything else — Javascript, Microsoft Excel, a pencil, Adobe Illustrator, a soldering iron, a coffee machine, MySQL, a pair of knitting needles — is a tool.

Designers cannot be identified by their tools because anything can be a designer’s tool.

That is, so long as it’s the right tool for the job.

What it is

The aria-controls attribute is a ‘relationship attribute’ which denotes which elements in a page an interactive element or set of elements has control over and affects. It’s commonly used to describe a relationship between a button and the expandable region revealed by that button.

<button aria-expanded="false" aria-controls="expandable">open / close</button>
<div id="expandable" hidden>content of the expandable region</div>

What we think it does

Wishfully thinking, we assume that marking up relationships with aria-controls means screen reader users can effortlessly flit between the moving parts of a web application, like a mechanic tinkering in a ship’s engine room.

Because we’ve used aria-controls, we don’t have to worry about source order, right? We’ve connected up the dots explicitly, with our magic attribute! And it doesn’t matter about all the elements between a controller and its subject because we’ve tunneled between them, right?

<button aria-expanded="false" aria-controls="expandable">open / close</button>
<div>
  <!-- a load of other markup, including interactive elements in focus order -->
</div>
<div id="expandable" hidden>content of the expandable region</div>

Good luck with that

First of all, only the JAWS screen reader supports aria-controls. If a user is operating NVDA or VoiceOver (or others), they would have no idea it’s even there. That’s reason enough not to use it.

But, just for giggles, let’s talk about how JAWS supports aria-controls. When you focus an element with the attribute included, JAWS will announce, “press the JAWS key plus Alt and M to move to the controlled element.” Verbose and clumsy. Then again, I’m not sure how else you’d go about supporting it.

But, that’s not the only problem. How in the hell do I move back? And, even if I could, how would that be communicated and how long should the option to move back remain active? No wonder the other screen reader vendors are giving this a wide berth.

Multiple controlled elements

You can create a one-to-many relationship by supplying a space separated list of ids, representing different, simultaneously controlled elements.

<button aria-controls="elem1 elem2 elem3 elem4">open / close</button>

Cute! And good luck with implementing a half-decent UX there, everybody. In case you’re interested, JAWS just says “press the JAWS key plus Alt and M to move to the controlled element” as normal. Genius.

Conclusion

The aria-controls attribute is a prime example of something we’d love to ‘just work’. Trouble is, there’s no clear way how it should work. JAWS makes a perfunctory attempt at implementation, but it’s incomplete and I suspect it creates much more confusion than it provides clarity for real users.

In the absence of a good purpose-built solution for letting folks using an interface aurally move between and around tools and their outputs, try a combination of the following:

• Same-page links to move users from one part of the interface to another
• Landmark roles to encapsulate major areas of the interface’s functionality
• Expandable areas that come immediately after their aria-expanded controllers in the source (and in focus order)

There’s also the question of ‘focus management’. In keyboard and screen reader accessibility terms, focus management usually means using the focus() method in JavaScript to move focus between elements. Be aware that, in almost all cases, users do not want to be moved from one place to another without their explicit say-so. Even when they do want to, providing a link is probably your best bet.

I think I’ll give the focus management wasps’ nest a proper poke on another occasion.

I’m also lazy, so it’s all gravy. (ed: maybe run with a food analogy?)

But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking. What goes in one end has to come out the other in some form, whether it’s broken down and liquified in the gastric juices of your task runner or not. (ed: I’ve changed my mind about the food analogy)

And that’s not all. Unlike aiming for ‘perceived’ performance gains — where you still send the same quantity of code but you chew it up first (ed: seriously) — you can actually make your Web Stuff cheaper to use. My data contract doesn’t care whether you send small chunks or one large chunk; it all adds up the same.

My favorite thing about aiming to have less stuff is this: you finish up with only the stuff you really need — only the stuff your user actually wants. Massive hero image of some dude drinking a latte? Lose it. Social media buttons which pull in a bunch of third-party code while simultaneously wrecking your page design? Give them the boot. That JavaScript thingy that hijacks the user’s right mouse button to reveal a custom modal? Ice moon prison.

It’s not just about what you pull in to destroy your UX or not, though. The way you write your (own) code is also a big part of having less of it. Here are a few tips and ideas that might help. I’ve written about some of them before, but in terms of accessibility and responsive design. It just happens that a flexible, accessible Web is one we try to exert little of our own control over; one we do less to break.

WAI-ARIA

First off, WAI-ARIA != web accessibility. It’s just a tool to enhance compatibility with certain assistive technologies, like screen readers, where it’s needed. Hence, the first rule of ARIA use is to not use WAI-ARIA if you don’t have to.

LOL, no:

<div role="heading" aria-level="2">Subheading</div>

Yes:

<h2>Subheading</h2>

The benefit of using native elements is that you often don’t have to script your own behaviors either. Not only is the following checkbox implementation verbose HTML, but it needs a JavaScript dependency to control state changes and to follyfill standard, basic behavior regarding the name attribute and GET method. It’s more code, and it’s less robust. Joy!

<div role="checkbox" aria-checked="false" tabindex="0" id="checkbox1" aria-labelledby="label-for-checkbox1"></div>
<div class="label" id="label-for-checkbox1">My checkbox label</div>

Styling? Don’t worry, you’re covered. That’s if you really need custom styles, anyway.

<input type="checkbox" id="checkbox1" name="checkbox1">
<label for="checkbox1">My checkbox label</label>

Grids

Do you remember ever enjoying using/reading a website with more than two columns? I don’t. Too much stuff all at once, begging for my attention. “I wonder which thing that looks like navigation is the navigation I want?” It’s a rhetorical question: my executive functioning has seized up and I’ve left the site.

Sometimes we want to put things next to things, sure. Like search results or whatever. But why pull in a whole tonne of grid framework boilerplate just for that? Flexbox can do it with no more than a couple of declaration blocks.

.grid {
  display: flex;
  flex-flow: row wrap;
}

.grid > * {
  flex-basis: 10em;
  flex-grow: 1;
}

Now everything ‘flexes’ to be approximately 10em wide. The number of columns depends on how many approx’ 10em cells you can fit into the viewport. Job done. Move on.

Oh and, while we’re here, we need to talk about this kind of thing:

width: 57.98363527356473782736464546373337373737%;

Did you know that precise measurement is calculated according to a mystical ratio? A ratio which purports to induce a state of calm and awe? No, I wasn’t aware and I’m not interested. Just make the porn button big enough that I can find it.

Margins

We’ve done this. Share your margin definition across elements using the universal selector. Add overrides only where you need them. You won’t need many.

body * + * {
  margin-top: 1.5rem;
}

No, the universal selector will not kill your performance. That’s bunkum.

Views

You don’t need the whole of Angular or Meteor or whatever to divide a simple web page into ‘views’. Views are just bits of the page you see while other bits are unseen. CSS can do this:

.view {
  display: none;
}

.view:target {
  display: block;
}

“But single-page apps run stuff when they load views!” I hear you say. That’s what the onhashchange event is for. No library needed, and you’re using links in a standard, bookmark-able way. Which is nice. There’s more on this technique, if you’re interested.

Font sizes

Tweaking font sizes can really bloat out your @media blocks. That’s why you should let CSS take care of it for you. With a single line of code.

font-size: calc(1em + 1vw);

Err… that’s it. You even have a minimum font size in place, so no tiny fonts on handsets. Thanks to Vasilis for showing me this.

10k Apart

Like I said, I’m not the best coder. I just know some tricks. But it is possible to do a hell of a lot, with only a little. That’s the premise of the 10k Apart competition — to find out what can be made with just 10k or less. There are big prizes to be won and, as a judge, I look forward to kicking myself looking at all the amazing entries; ideas and implementations I wish I’d come up with myself. What will you make?

The set is very sterile. Reassuringly tidy though. No dashboard dross or the like.

I like how the first baddies introduced (the Ferenghi) are described as “capitalists” and therefore evil. They act a bit like the crappier orcs out of LOTR.

It’s nice how everyone gets on so well with Worf. I expected a little bit more anti-Klingon racial tension, though. Be interesting if it came from Geordie. I like to imagine Worf’s sash is from winning a beauty pageant.

It occurs to me the Klingons are a bit like the English. Wedded to the past and needlessly combative.

Doctor Crusher: Name of a hip-hop producer, face of someone who’s very much not a hip-hop producer.

The Captain’s role is bitter sweet. He’s a sort of childless father. Comforting BBC Radio 4 voice.

I think Deanna Troi should have a smaller part. Way too much mission-critical stuff depends on her telepathic ‘insights’. Doesn’t seem like a good protocol. I imagine she was called Diana Troy, then changed her name when she found out she was a telepath. Pretentious.

The computer interfaces look to me like they could benefit from some clearer labeling and better differentiated colors.

All alien races like shiny clothes. Space is camp AF.

Yar is my second favorite after the Captain. I like that the security officer is a woman. Lovely, wispy hair.

There’s something unseemly about Riker. He constantly looks like he’s trying to brave his way through a sex scandal.

Wesley gets an inordinate amount of romantic attention. It’s a mystery to me how.

Data scares the shit out of me. I know he’s an android, but I just see a psychopath. I keep expecting him to suddenly and indiscriminately strangle one of the other crew members then tilt his head and say “most curious” when they stop struggling.

There are a lot of alien forces which all seem to exist for the sole purpose of creating existential crises.