DEV Community: Claire Lipskey

Why can't we solve accessibility with a one line script tag?

Claire Lipskey — Sat, 07 Aug 2021 04:29:38 +0000

This is a good question. There are some companies that'd like to beg to differ (such as AccessiBe, which is rubbish). This post is not for them. It's for you. They know what they're doing (and not doing).

// Detect dark theme var iframe = document.getElementById('tweet-1421660430217490433-445'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1421660430217490433&theme=dark" }

To start: the web is (generally) accessible by default.

We break it. Me, you, companies, capitalism, you name it - that's what breaks the web from being accessible.

<div> tags with an onClick event when the <button> element is right there, modals that don't trap focus, and other examples are rampant throughout the Internet.

Let's think about this from the angle of how your code is interpreted by the browser and accessibility software:

Write some HTML.
Load that HTML into a browser.
The browser interprets that HTML, and creates an accessibility tree out of it (among rendering it, etc)
The browser exposes an API that accessibility technology accesses, and a browser interprets the HTML as if it was written to standards.
- If this HTML is not up to spec, such as being used improperly (looking at a <div> with an onClick event, for example), the browser cannot infer what exactly that is for.
- This affects the accessibility technology, as it can only do with what the browser provides.

If we use web technologies improperly, do we expect a browser to somehow perform heuristics to get what we mean? After all, programming is literally telling a computer what to do in a language it understands. If we do not tell it what to do in a way it understands, it will generally take the safest path.

An example of this is correcting for when a closing HTML tag is missing. In older browser days, the standard allowed for certain tags to omit a closing tag and that was valid HTML. That's not the case anymore (except for certain exceptions, like <input>!).

Take this code:

<div>
  <span>Hello!
</div>

In any modern browser, the <span> above will be automatically closed in the DOM if you inspect it.

In the source above, there's not even an HTML tag, HEAD tag, or BODY tag, yet Firefox assumes it anyway. The browser can help us in many ways, but it cannot get our intent out of our badly formed code.

Sometimes, the standards aren't all we need

In other instances, we can correctly use all HTML tags and still not make an accessible interface. This is where the nuance comes into play. For example, a modal. By definition, a modal is simply a dialog over top other elements. The user experience dictates that this is treated as a separate "document", and there's no standard way to do this. Modals in general break the way the web was created. A page is a "document", yet a modal is a "document within a document."

If a document is to really behave like a document, then it must be the sole document "in focus." With modals, we generally add a "focus trap" to make sure that users cannot get out of it unwillingly. A bolt-on script will not know this is what you intended.

There are some instances where we need JavaScript in order to make the web accessible. Stephanie Eckles wrote a really good Smashing Magazine article that expands on this.

How does someone's JavaScript know this nuance?

It doesn't. It can't. It won't. And users that need accessible interfaces and experts in the field have said time and time again that it doesn't work.

Don't resort to bolt-on fixes

AccessiBe isn't the first company to do this, but it's making big promises and being slimy in the process. There are others named in the Overlay Fact Sheet - they should all be avoided.

Accessibility is not a bolt-on.

Front-end development is not automatically easy. Project timelines should reflect that.

Claire Lipskey — Sun, 07 Mar 2021 04:58:01 +0000

(thanks Unsplash for the cover image)

I've had the title of "front-end engineer" in some sort of capacity for almost 9 years now. In these 9 years, one thing has not changed:

| "Oh, that's just HTML and CSS, that'll take like, 2 days right?"

This could be true, but it is not usually true. We see this in discourse on Twitter, in meetings throughout our workplaces, and in general the vibe that front-end is not really "development", "engineering", or "programming".

Why do questions / statements like this matter?

This sentiment towards a craft really "grind my gears" so to speak. It emboldens the following assumptions:

That front-end (HTML, CSS, and JavaScript) languages are easy.
That there is no lead time to "getting things ready"
That there is no lead time to really get a project into a "let's go" state.
That there is nothing to clean up (if it's an existing project)
That you can write code once and it works and it's good to go (browser testing across devices is a thing!)
That organization and writing clean, maintainable code takes no time at all.

These assumptions are harmful to any craft - but we see it all the time with front-end engineering.

What is a better response?

Timelines are important to any project - I'm definitely not disputing that. Front-end engineers are usually sandwiched between design and back-end engineers - both of whom are usually given a bit of lead time to really understand the problem. Many front-end engineers want to be and need to be part of that lead time / discussion.

Ask the ones writing the code
This might sound wild, but ask the people who are making the changes and adjust your business priorities accordingly. They may waffle on an answer, but their waffling is also a good indication it may take a bit more time than you realize.
If you allow time for design, allow time for development
It is not unfathomable that the time it took to research / come up with finessed designs might be around the same time a developer needs to execute the designs.
Give front-end engineers the respect they deserve
Front-end engineers have to support a wide range of clients, deal with languages that are constantly changing (like, literally, every 4-6 weeks a browser might support something new), and constantly have to watch out for themselves by not painting themselves into a corner when a new design comes across the table.

Design is not easy.

This applies to the actual creation of designs (UX, visual, content, etc) but also architectural design of a codebase. Companies all the time find themselves in a situation where a codebase is not "feasible" to be upgraded because things weren't thought of when it was designed.

How do you overcome this problem?

Slow down. Take a bit more time to create a scalable system, no matter the language, that can take you from small to large. I'm not advocating for perfection - I'm advocating for sensible and pragmatic development.

Invest in what you're making - whether you're a small startup or a company that can throw tens of millions of dollars at a project on a whim.

Allow your engineers this time. It will help you (and your team) later.

Developing with Empathy: Using a Code Style Guide

Claire Lipskey — Sat, 12 Sep 2020 03:33:31 +0000

Being a developer doesn't mean you're just coding all the time. You code, but you also communicate, interact with other people's code, maybe even get on a zoom call. Whatever it might be that you do, being on the same page is probably a good idea.

In my various development experiences, I've found that setting expectations of what "good code" or "clean code" looks like is a great way to help folks who do not necessarily know what questions to ask or if they even have any questions.

What is good code?

Well, honestly, good code is what you make it to be. As long as it works / compiles / whatever, it's code. You can show your fellow coworkers / cohorts what good code looks like, but until you write down or codify (giggle) what that is, folks are going to write what they want to get the job done.

Why is this necessary?

For a lack of better jokes: so that everyone is speaking the same language. If everyone writes code similarly then it helps code reviews, discovering bugs and pairing in general. I find myself doing at least two things before I really can start thinking about the problem being presented to me when I am pairing with someone:

Adjusting to the style of the code, whether that is the organization of the CSS rules or how abstracted the JS is.
Re-reading through everything before making sense of it and making recommendations.

I feel like this goes faster when everyone kinda does things similarly.

Style guides help do the following:

Ensure everyone is writing similar code
Ensure readability
Ramp up new developers to the "expectations" of "good code" or "clean code"
Clears up any issues regarding the above otherwise vague terms.

What does a good style guide look like?

Well, again, that's up to you! I have some recommendations, though:

CSS

Javascript

There are many others out there, and some of those out there come with their own tooling, such as Airbnb's banel-preset-airbnb or even StandardJS' npm install standard.

Being on the same page with your team with regard to "good code" not only improves communication and team dynamics, but it reduces the "omg who wrote this?" reaction you might have before you pull out git blame :)

Developing with Empathy: Reusability

Claire Lipskey — Thu, 10 Sep 2020 19:01:02 +0000

"Reusability", "Reusable Components"... we've all heard it before.

In my last post, I spoke about the Single Responsibility Principle. Now, if we take this idea and apply it to "reusable components" or "reusability" it makes total sense. But aside from reusable components, what other ways can we make our code more modular and reusable?

Let's put it in the context of the code below:

index.html

<script src="date.js" type="text/javascript"></script>
<form>
    <input type="date" id="date1" name="date1">
    <input type='date" id="date2" name="date2">
    <button>Submit</button>
</form>

date.js

document.addEventListener('submit', () => {
    let date1 = document.getElementById('date1').valueAsDate
    let date2 = document.getElementById('date2').valueAsDate

    console.log(Math.abs(parseInt(date1 / 60 * 60 * 1000 * 24) - parseInt(date2 / 60 * 60 * 1000 * 24)))
})

This is a very rudimentary example, but I have found a lot in my experience as a front-end engineer that when writing code, sometimes there is not a thought to abstract something that could be calculated / used somewhere else.

How might we make the above code a bit more abstract? Or how might we break out some functionality to be able to be used elsewhere?

Take this modified code sample for example:

date.js

document.addEventListener('submit', () => {
    let date1 = document.getElementById('date1').valueAsDate
    let date2 = document.getElementById('date2').valueAsDate

    console.log(calculateDaysBetween(date1, date2))
});

function calculateDaysBetween(date1: Date, date2: Date): number {
    const toDays = 60 * 60 * 1000 * 24;
    return Math.abs(parseInt(date1 / toDays) - parseInt(date2 / toDays));
}

The above takes the hard-to-read bit in the console.log() from the first script block and makes it easier to read and makes it so we can call it anywhere.

Writing code in a way that is very easy to read is caring for your fellow developer, and it makes it easier for you to come back to in a few months and not want to pull your hair out!

Happy abstracting!

Developing with Empathy: Single Responsibility

Claire Lipskey — Sun, 12 Jul 2020 19:47:46 +0000

Single responsibility is a concept that has been around for a while.

Wikipedia defines it as:

...a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

This helps your codebase be easier to maintain, easier to debug, and easier to learn.

Do one thing, and do it well

Whether you’re building something for yourself, you’re the only one on the team, or you’re part of a giant development team - there's a certain need for having an “orderly” way of “doing things”.

In my intro post, I started off the introduction to this topic by saying:

script.js is so 2014

Think about having all of your current JavaScript code in one file. It used to happen! It still does happen. It’s daunting for anyone coming into a project. Sure, you can help supplement the knowledge you’ve dumped into it by annotating with comments or naming your functions properly, but it’s still a daunting thing to look at.

Imagine coming into a project for the first time. You’ve been tasked with updating this function on a website:

$('.price').on('click', function() {
  $('.item').css('color': 'green');
  $.ajax( // stuff );
});

The above creates an event handler via jQuery (don’t get me started on jQuery), but doesn’t really infer why it exists.

The switch to component-based architecture in the front-end world and really just the transformation of JavaScript from being simply a DOM manipulation tool to a complex infrastructure language (thanks Node) has brought about a lot of change to the ways we write it.

In an Angular 2+ world with TypeScript (when written according to John Papa’s Angular Style Guide), the above code would be written in at least three different files, like so:

// price.component.ts

import { TransportService } from "../../services/transport.service";

@Component()
export class PriceComponent extends Component implements OnInit {
  @Input() price: number;

  constructor(private _transportService: TransportService) {}

  ngOnInit() {
    this.addEventListener('click', (e: MouseEvent) => {
      this._transportService.send('stuff');
    })
  }
}

// transport.service.ts

@Injectable()
export class TransportService {
  public send(item: string) {
    // do stuff
  }
}

There would probably be another file to act as a state class across modules (another Angular Service) to change the CSS as in the first example as well, but I think you get the idea of what I’m going for here.

Writing more code isn't necessarily a bad thing

I find myself being verbose in my writing of JavaScript / TypeScript nowadays, and I don’t view that as a bad thing.

Verbosity in code isn’t inherently inefficient. It isn’t going to slow down my application, at least in a way that’d really matter. Tree shaking and whatnot exist now! Let things be singletons. Let things do exactly what they should do and not a thing more. There was a time when we didn’t compile our JavaScript code, and it made sense to not be verbose. But now, now that we can compile our code means we can be verbose too. The front-end world gains access to a lot of things back-end / compiled languages have enjoyed for a while with these new tools.

I’m of the opinion that it doesn’t go against the idea of pragmatism to be a bit verbose. Writing a bit more meaningful code than would be necessary for the now makes my job of maintaining / adding / scaling the thing I’m doing now easier for me (or someone else!) in the future.

Of course the jQuery code listed first above would work for the purpose we’d want. It did back then! It would do so still. But there’s a way, and then there’s a better way (for all those involved).

My codebase isn't built with this in mind. Do I have to scratch it all?

Codebases are always changing. We’re always adding to them, deleting from them, and manipulating in between. Start on the path toward single responsibility.

I’ve encountered this in the past. I came into a codebase that had several different frameworks within it. One was used in one part of the app, another in another part. No real rhyme or reason for any of it. I made it my duty to go through and bring everything under the same umbrella.

Developing with empathy means that you keep the following in mind:

the person before you may not have had the time to think about the bigger picture.
the person before you may not have had the technical know-how to always think about the most common denominator.
you should leave the codebase in a better state than it was before you arrived.
the people you work with now are likely to need your help in keeping the codebase healthy.
you can’t solve everything.
the person after you could very well be in the same position you are in right now if you don’t fix what you can.

I made my aspirations for the codebase part of the expected work and not just “outside” the realm of the project work.

This meant bringing items that did similar or even the same thing into one hunk of code by introducing reusable components.

I've already employed this strategy. I'm good to go.

Is it? This isn’t a “we built it with this in mind” kind of topic. Quite the contrary - what you wrote on Friday, was it built with this principle in mind? This is an always on principle, and without it always on, you can get lost from it pretty quickly.

At a previous job, my team and I for the most part maintained this principle. This was a codebase I led for a while and I still let some of this slip. It came back to haunt us! When asked about x being a reusable component, I had to admit that it wasn’t, that it was built specifically for a particular purpose because we didn’t have enough time to generalize it and merge it into our existing patterns. It’s not a failure - but it shows that it requires constant communication with project leaders, designers, and everyone else on the team to maintain a codebase in the most optimal way.

This doesn't just apply to JavaScript / TypeScript

Single responsibility makes its way into CSS too. OOCSS, BEM, and all the other "ways" of doing CSS make some part of this part of their schema too. I'll expand on this in another post.

tl;dr

Writing a codebase with single responsibility in mind is hard work. It takes a lot of thinking and planning to be comfortable breaking complex ideas up into small bits that all do “their own thing” and can be reused. However, it allows developers and teams alike to work quicker, increase speed and efficiency, and helps onboard new developers and instills good heuristics on what should be “new” and what can be reused.

Developing with Empathy: Introduction

Claire Lipskey — Wed, 08 Jul 2020 19:26:23 +0000

Hi!

My name is Claire. I am a front-end engineer in Chicago. I really enjoy writing code, and seeing what that code can do.

I want to talk about what it means to be a developer / engineer / do-er.

There are a lot of things that many folks consider metrics for how "good" I am at my job:

Performance. This might come in the form of a Lighthouse score (or insert Your Favorite Tool Here®), or something more low-level like the complexity of a function and how well it performs (such as the dreaded "Big O" notation - more on that later)
Soft skills, or how able I am to disseminate a topic of great technical complexity to someone who does not share the same skill set as me.
Speed. How fast am I able to ship a feature? When that feature is shipped, is it riddled with bugs?

Those are familiar metrics to any developer. I'd argue, however, that there are more. More that we don't ask about in interviews, more that we don't really grade each other officially, but know implicitly about each other.

We all have our styles, but having a core set of values in a development team leads to a lot of good. That's what this series is all about.

I want to talk about the following more at length. Expect these to be their own post(s) in the future!

Architecture: Is the architecture you're building reasonable? Believe it or not, you're building architecture every day. Every bit of code you place into the codebase is part of the architecture. Does it make sense?
- Consistency is key.
- Folder structure shouldn't be dictated by one side of the codebase.
Tools: Do you monitor and ask why when someone adds a new node module? Did you choose it because it is shiny?
- Less is more.
- Fundamentals are forever.
Discussions: In the world of COVID-19, a lot of us might know what it is like to be thrown into a new work-from-home-indefinitely position. Have your "go to someone's desk and ask a question" discussions directly transitioned to just a DM on Slack? Is that good?
- When does it make sense to become a video meeting?
Single Responsibility: script.js is so 2014. Components! Atomic Design! Insert system here! Single responsibility is, in my mind, one of the best ideas to come out of the UNIX world. The command cd doesn't also make directories, does it? No. It only changes the active one. The things you build should be the same way.
Pushing back, but in a good way: We all know the stereotype of the developer who states “Nope, bad idea. Don’t like it. Won’t have it.” I’ve worked with them before. Pushing back is a good thing when it’s done empathetically. I find myself day in and day out pushing back on ideas designers, product folks, and even back-end developers give me.
- How do you keep it from being “gatekeeping”, though?
Building for everyone: Accessibility. It’s not a buzzword. It’s not a bolt on. It affects you if you write only JavaScript. It affects you if you write anything for the web.
- Don’t sacrifice accessibility because of time.
- Don’t sacrifice accessibility for anything.
Who really is the customer anyway?: Is it John or Jane Doe who visits example.com? Maybe. But I’d implore you to think of the person who fills your chair after you leave to the next line item on your resume. They’re important too.
- Will they understand what you’ve written? My experience is that if there’s a damn good reason for something existing there and there’s documentation to boot, I’m much more inclined to not touch it.

This series kind of sounds like it might just be about how to be a good developer / engineer / do-er, and you might be right about that. In order to be good at our job, we must always be thinking of who the customer is - and the customer is not just the end user. Developers - yes, you! - are also the customers.

These are the general topics I want to hit on, and there might be multiple posts per topic, and even possibly a topic not on this list! I want this series to not only explore all the different ways we can add / lead with empathy, but also expose that for myself. This is a writing journey for me, and I hope you find it useful too.

Our product really is the code we write, the discussions we have, and the feelings we leave with others. Developing with empathy will get us all to a better, more inclusive and helpful development world.