Accessing accessibility: Some SEO-friendly tips

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

According to the 2012 U.S. Census, almost 60 million Americans (nearly 20 percent of the U.S. population) have some form of disability. While not all of these disabilities may affect the way people interact with your website, a large population of your potential users probably can’t use your website the way you expect them to. For any company, but especially ones like Scripted that prides themselves on words, this is often an overlooked trap.

Accessibility is not just about making it easier for people with disabilities to interact with your site. Instead, making information easier to consume and understand should be your primary goal. These tweaks can be simple, such as using the appropriate H1 tag versus a stylized div for your main header and having links that are descriptive on their own rather than just saying ‘click me’ or ‘here’. Keeping accessibility in mind also allows you to build a better organized, more SEO-optimized, and easier-to-navigate app for all of your users.

A good place to start optimizing is by running your site through Addy Osmandi’s A11y tool. Running the online A11y URL checker against a page will give you a list of warnings.

A11y warnings for Scripted home page

In Scripted’s case, the home page had some warnings about hidden links and was missing some alt tags for images.

A11y warnings for Scripted order form

Scripted’s order page had some severe shortcomings regarding labeling inputs. Without input labels, many screen readers can only guess what your forms are trying to collect. And as a secret bonus, input labels make the clickable surface of your input bigger. A tiny radio button without a label means the user can only click on the radio dot to choose an option. With labels added, they can click anywhere on the radio or surrounding label to make a choice.

    <label for="content">
        Custom Content
        <input type="radio" name="content" value="custom">
    </label>

A11y passing tests

After adding the labels and making some of the other suggested tweaks to both the homepage and the order flow, the report is looking much better, but one file change won’t solve all your problems. Someone on your team might make a change next week and forget to include an alt on an important image without thinking about the impact. You need a plan! Whether it’s running the URL checker on a regular basis or asking the team to keep accessibility in mind during code reviews (and training them on what to look for), figure out a path that will help you maintain the accessibility of your site. For both quick fixes and good basics on accessibility, a great resource to start your team with is the A11y project.

Flexbox: Tables of the Future?

This post was originally written for my work engineering blog. Check us out and see some interesting articles from my coworkers at goats.scripted.com.

The greatest CSS gif of all time

What is flexbox?

Most websites design around grid systems. A long, long time ago, in Internet years, this was done using frames and actual table grids. Then we all moved on to floats and percentage widths. The Holy Grail layout was often a mess of different solutions. Flexbox is a CSS layout mode that gives you complete control over the components you put in your grid, allowing you to keep sizing organized both inside and outside the box, as well as providing a unified layout styling no matter what screen size you view the components on.

How we use flexbox at Scripted

Flexbox is used at Scripted in a number of locations. Most of our marketplace pages are large grids of cards, and each card is itself a grid. In order to accommodate lots of information about each blog idea, we need to be able to keep sizing consistent with inconsistent data. Our CSS is compiled so we are able to make mixins for flexbox that do the heavy lifting (and solve a lot of cross-browser compatibility issues) for us on the fly.

Flexbox in actionFlexbox in action

On the page above, for example, each card uses our standard flex layout. We added the option of a column direction, meaning information should flow down the page, and each component in an individual card should stack. For the overall grid layout of an unknown number of cards, we use the standard with an additional wrap option so cards flow to new lines when we run out of space (versus trying to crowd them onto a single line).

Why not flexbox?

Unfortunately, like with most newer web standards, support and implementation haven’t had time to unify. For example, Internet Explorer — because it’s always the example with new designs — implemented an outdated flexbox interpretation in older versions. Even with current flexbox standards, different browsers render flexbox styles differently.

Other concerns, especially for sites trying to use flexbox for their overall layout, is the speed of rendering. While it’s a few years old, Ben Frain’s look at the speed of table CSS versus flexbox is a good start. Rerunning the tests now shows some better numbers for flexbox layouts.

We still use table layouts for assets that we want to just work; some of our feature charts are examples of this.

Other resources

While it still has some quirks, depending on your project and your commitment to polyfills, flexbox is a powerful tool to build some really nice layouts. To get started building your own, Sketching with CSS has the ultimate flexbox cheat sheet. And of course, Mozilla Developer Network has a full rundown of flexbox layouts and links to many tutorials.

No News is Good News? or A Short Discourse on Pair Programming

Things have been quiet here at casa de Lindsey which is good for me, but probably not as exciting for the people who (maybe, sometimes?) read this thing. Since April I’ve been relearning why I love being a software engineer in a supportive and awesome culture at Scripted. It’s a small tight-knit team and I was a little worried about coming in as a newbie to a solid team but they’re amazingly lovely people and I love learning with them and from them. Front-end only land has been so busy I still haven’t had time to really even touch my first love of backend APIs (which would require me to learn Rails to do it justice at Scripted) but I haven’t really mourned that loss. Instead as one half of a front-end team of two I’m running around like crazy helping our backend/full-stack team be better front-end engineers, sitting down with our designer to craft better UX and handholding our marketing team through WordPress template changes when the starts align correctly.

Which brings me to my continued sermon on mentoring/pair programming and how much I luuuuuurve it. I keep reiterating it, but I’ll continue to reiterate. I love mentoring other engineers, I love pairing with people. It can be super awkward at first, because even if you’re the one who is supposed to be mentoring you won’t have all the answers. But that’s not the point! The point is for you to foster learning, for you as well as the other person. Software engineering is not a perfect set of knowledge that you can learn once and then just churn out the same thing over and over, but it’s also not always about going down the rabbit hole of discovery (especially if you have to earn a living writing code for a living). Mentoring and pairing almost feels like cheating to me, because I don’t have to solve all the problems myself. I might not even have to come up with the original idea for something, just help refine it and still get to take partial (but deserved) credit in the end.

Also there are so1 many2 better3 resources than my stream of consciousness musing on pair programming (and a MAJOR SHOUTOUT to a study on the benefits of pair programming for women – hint: it benefits everyone). Please check them out, give it a shot if you can. It is really, really hard at first and it’s definitely not for everyone but for me and most of my pairs it just takes so much stress of the engineering cycle.

Expect more posts soon, I’m thinking of trying my hand at “teaching” since I can never have enough “lemme just show you this one cool thing” moments. If it all works out it will probably be a series of posts a la “I don’t want to make another to-do app in JavaScript to level up my skills”.

 

On to Smaller and Better Things!

My time with Udacity has come to an end. I made some amazing lifelong friends out of it and learned enough to fill a book but I decided it was time for me to trundle along to a new opportunity. So I’m excited to announce that I’m joining Scripted as a JavaScript Engineer! It’s going to be a bit of a brain warp focusing most of my efforts on the front end but I’m ridiculously excited for the opportunity and working with the awesome new coworkers that I’ve met so far. The team is much smaller and very careful to cultivate their culture and I just felt right at home the minute I came on site for my interview with them (as an aside: sort out culture fits first or you will be miserable no matter how potentially amazeballs you think a project is). I really look forward to diving back into my JavaScript roots and being able to geek out about all the upcoming changes.

My other hope in this transition is to get back into mentoring more. Working in Mountain View and attempting to mentor in SF was super draining on me, but now that I’ll be working in SF, I want to pour more of my free time back into mentoring and helping others join this awesome ride that is the tech industry. So I’ll be spending some time to think about how to approach that aspect.

Reminder: Choose For Culture!

Lately I’ve been interacting more and more with people trying to break into the tech industry. It’s something I’m keenly aware of as a recent wall breaker myself and my general desire to mentor and champion other people to do what they want.

I recently had the privilege with my co-host and awesome, awesome person Jennie to lead a talk for Udacity Nanodegree students on how to get into the industry and how to make connections/get a job/etc. I wish I could link you all to it, but it’s behind a paywall currently. Lies! Youtube video:

The talk itself was pretty standard:

  1. Network, network, network.
  2. Recruiters can be your friend/spy.
  3. People are generally nice, especially when you don’t spam them and actually ask them things that are relevant to them.

But between that and a lot of the recent articles on tech interviewing/culture (which I’m not going to give my opinion on in this post as it’s nuanced and hard, but spoiler: pair programming interviews are the bomb) I’m a little dissatisfied that I didn’t mention my number one rule for finding a job:

CULTURE IS THE MOST IMPORTANT FACTOR

I’m not going to pass judgement on different cultures as people are, shockingly, different. Just know that if you have the luxury, which thankfully is often the case in tech, please, please don’t choose a job just for prestige or some weird convoluted inner turmoil. Make sure your coworkers are rad. You will need them, a lot. Many of my best friends now are former/current coworkers. We have nerdy parties, we play video games, we send each other stupid cat gifs (okay, that’s just me sending them out to everyone else, but they appreciate them damn it!), but more importantly they have my back. They can help me troubleshoot stupid mistakes or understand my inner rage at a feature or just geek out with me over the hot new programming hotness.

I think a person I follow on Twitter put it best when he said:

https://twitter.com/tef/status/578676050055561216

Week 2: Ticking All the Checkboxes

How is it possible that I’ve already been working for Udacity for two weeks?!

I have done real tangible things since last week (I did real, tangible things my first week but nothing I could really point you to). This week, I integrated Github linking!! If you have an account on Udacity, you can now link your Github account to it here. This doesn’t actually do much more at the moment, but it’s all a part of a master plan. If you don’t have a Udacity account (why not?!) or aren’t using Github, here’s an action shot from my account:

My first contribution to Udacity

I’m settling in to my place a little more (I also discovered the spider I threw outside was not Selma, but Selma is in fact outside now too). I have a new whiteboard that is currently just practical (groceries and upcoming things), but I’m sure it will end up with weird pictures of animals and penises.

The Whiteboard of Doom

My plans this weekend involve groceries and finally getting a San Mateo County library card, so I’m pretty excited!

Week 1: I Feel Like I’ve Been Here Before

First week of work is over and it felt a lot like a less intense week of Hack Reactor. I still can’t believe this is what I’m actually doing with my life. I still definitely have lots and lots of impostor syndrome but I also deployed live things my first week! And learned a few of my coworkers names! And did a two minute all staff demonstration on how to knit!

I also got exactly what I wanted. I’m working full stack in JavaScript and Python in non startup-y startup (e.g., we’re not out to make lots and lots of money or making a product we don’t believe in for the money) doing things that I feel are making a tangibly good contribution. We have a gong that gets rung when a person graduates a class. That small bit right there proved that I was exactly where I wanted to be.

And yes, I’m still terrified some days that I’m too slow or too newb or just not cut out for this, but here’s a secret, I don’t think that will ever go away. Maybe it’s a good thing or maybe it’s just human nature, but I just need to learn to live in my own skin I think and take the impostor syndrome as a mark of being human, of caring about my work and wanting to always get better.

And a minor update: Selma is no longer in the house, I got the balls to move her outside finally.