Good Accessibility Means Quality

Cracked concrete with green tint.

WebAIM recently released a report about how accessibility errors permeate the Web. The report states, “the results paint a rather dismal picture of the current state of web accessibility.”

If you’ve ever tested sites for accessibility, the results may not surprise you. I can tell you in my own work, I see a lot of the same mistakes repeated. Depressing, indeed.

Eric Bailey wrote about the results eloquently. He compared inaccessible websites to structurally unsound bridges. Would you use a bridge with possible known faults? No. Yet, we ask people to do this every day with inaccessible sites.

Ethan Marcotte issued a call to action in his post about the results. He asked us to ask ourselves, “What’s one thing I wish I understood better about accessibility?” He even recommended my own Accessibility Weekly as a way to learn. That question rattles around in my brain constantly. So much so, I wrote a few blog posts about questions I get around the topic.

But one of the questions that I keep coming back to the most?

Why is accessibility not as exciting as say some new JavaScript hotness, CSS technique or [insert web thing]? If it were, maybe we wouldn’t be in this sorry state?

I don’t have the answer there, only some hypotheses.

Hypothesis number one: Inclusive design and/or accessibility shows a sign of quality. For some web workers (myself included!), you can ignore quality at times. Like a concrete slab being laid level and smooth. If it isn’t level or smooth, many may not notice. Some will though, and over time, that slab will break down quicker than one laid right. Ignore accessibility, and your experience will deteriorate faster.

Karl Groves has written about quality problems related to accessibility before.

Marcy Sutton’s A11y Wins blog has great examples of paying attention to quality.

Hypothesis number two (related to one): Most accessibility challenges come down to three factors: decisions, people and details. I wrote about this in the past in a series I called Everyday Accessibility. We won’t make all the right decisions. People won’t always know enough about how to design or build an accessible experience. Details come and go so fast in projects that we may not pay attention to enough of them. These factors help drive quality.

Let’s focus on making the concrete a bit more level every time way lay a new slab. Anyone can make the Web more accessible one change at a time.

Image courtesy of Mahdis Mousavi.

Accessibility Answers: Is Safari Better than Chrome for Accessibility?

Woman sitting and raising her hand beside another woman.

When I give presentations on accessibility, I usually get one or two questions I’ve fielded before. I’ve collected a handful for an ongoing series of posts with my answers. I hope they help you understand accessibility better.

Is Safari better than Chrome for accessibility?

No.

That’s the short answer, but let’s go deeper. People often ask this type of question because Apple has developed a good reputation around inclusive design and accessibility. Maybe its browser has an edge? They also wonder what browser and screen reader combination work best together.

All valid questions, but in today’s “modern web” most browsers are comparable when it comes to accessibility features. If you’re testing your design or development work in a browser with a screen reader, you’ll want to stick to a few combinations:

  • VoiceOver with Safari on MacOS and iOS.
  • NVDA with Firefox.
  • Edge/Internet Explorer 11 with Jaws.
  • Talkback with Firefox or Chrome.

This post from Maxability on screen reader and browser combinations has more information. And if you want some survey data on screen reader usage, WebAIM has puts together some on a regular basis.

Follow the series Accessibility Answers. Ask me a question via my contact form or Twiter.

Image by rawpixel.

A Distraction-Free Phone

Several people looking down at mobile phones.

Lately, I’ve wanted to be more intentional instead of more productive.

Why check off another item on the to-do list when you can focus on completing the right task? Getting there means improving habits, and creating the space for the right things. The biggest opportunity for making that space sits in my pocket or next to me almost 24 hours a day. My phone.

Inspired by the book, Make Time, which I finished recently, I decided to radically alter my phone, a Pixel 2 XL. I disabled all the apps that prove most distracting. The ones that lure you in with a feed that goes on endlessly. These apps remove you from your place in life. They put you half in, half out, like some sort of spirit caught between two worlds.

No more. Here’s how I did it.

I downloaded the Digital Wellbeing app from the Google Play Store. This will be released later this fall as part of Android. The app allows you to set timers for all your apps. Once you run out of time, it locks the affected app. I set a zero-minute timer for all the apps that distract me the most. They are:

  • Chrome
  • Gmail
  • Twitter
  • Slack
  • YouTube
  • ESPN

That way, if I want to use these tools, I have to be intentional about it. I can’t just mindlessly click into them and lose time.

So far:

  • Having an extra barrier does help. I’ve spent a bit more time on my laptop, but I’m being more intentional there as well. Getting a task done and moving on.
  • I’m spending less time fiddling with email or opening up an app without a strict purpose.
  • I have more mental space for thinking and writing.

This isn’t my first foray into a more distracted-free lifestyle. I started reducing the number of apps I use on my phone two years ago, and have mostly stuck to that.

Image by Robin Worrall.

Important Things to Say to Your Team

Leading a team means you’re context switching all the time.

One minute, you’re doing some planning for a project. Next, you’re chatting about someone’s career goals. Later, you might be scanning your roadmap, thinking over what needs to be tweaked. With all that swirling around each day, it’s difficult to keep the important messages in mind for your team.

Think of how your team feels. They do the work, and probably have more on their plate than you. How do they remember what’s important? I’m not talking about your company or team goals, but the messages that will motivate them and make them think deeper about things like company goals. My leadership coach, Akshay, calls these “campaigns.”

To make this easier, I wrote a list.

  1. We should be building the fire suppression system, not the putting out all the fires.
  2. How does it look on mobile?
  3. What problem are we solving here?
  4. We’re not just about themes anymore.
  5. Make the future.

I look at this list at least once a week, trying to work it into conversations and communications with my team when it fits. The list evolves over time, but the themes within stay similar. They range from the everyday details that translate the craft to broad messages that grant perspective.

How are you communicating with your team? And are you saying the important things?

Be the Leader You Wish You Had

Clark Scheffy wrote an insightful post about how he evolved into a better leader. My favorite quote:

This is about what I learned the hard way: That great creative leadership is about letting go of that nagging mental image you have of what you are supposed to do. It’s about believing in others, and focusing on fanning the flames of creative, weird, exothermic people, rather than on fixing problems.

I like the message on perspective. It’s all about your perspective.

Hat tip: Megs Fulton.

Coding with VS Code

I confess, I switched editors again. 🙂

I first heard about Visual Studio Code on the Toolsday podcast, but didn’t give it much attention. I had recently started coding with PHPStorm, and was trying to embrace working with an IDE. Before giving it a go with PHPStorm, I enjoyed using both Atom and Sublime.

But a few weeks ago, I started using VS Code every day. I haven’t looked back. Here’s why:

  • VS Code really does blend the best of both worlds: a code editor and IDE. I like how I have all the features of Atom and Sublime, with a dash of PHPStorm.
  • My favorite feature so far? The built-in console. I love that I can do a lot of tasks in one app.
  • It feels faster than Atom, and certainly less cumbersome than PHPStorm, my biggest criticisms of each of my last two editors.

I haven’t run into many challenges in the switch because I tend to keep my editors lightweight, not using dozens of extensions. I have encountered some on and off issues with my PHP CodeSniffer and PHP executable configuration lately. I think it may be related to an existing bug in the extension though.

My current extensions include:

We’ll see if I run into any more challenges the more I use the editor.

Work on the Right Thing

We always think we can do more than we can. Myself included. That hasn’t changed since taking on a leadership role.

Multiple bosses have told me that I “take on too much.” Recently, several members of my team said the same thing to me. Why do I do it? Lots of reasons. Like my team might already have a big to-do list so I don’t want to burden them. Or I want to contribute, and feel like I’ve knocked something off the list. I might even think I can do it quicker than anyone else.

No matter the intentions, many times those reasons end up being selfish. Especially if I fail to help my project, team or company.

Daily habits and routines build up from triggers – the thing that starts a habit forming. I’ve found two triggers that have started helping me make sure I’m working on the right thing:

  1. If I have the urge to add a task to my to-do list, I ask, “Will this help my team or a specific project?” If they answer isn’t “The team,” I try to delegate the task.
  2. When I start a task, I try to ask myself the same question. That way, I have a filtered process, meaning it’s harder for the wrong tasks to make it through to my day.

I’m not perfect, but using these triggers has meant delegating more and working on the right things for me. If I hesitate, I try to think of the advice my colleague, Brie shared – “Delegate until you’re uncomfortable. If that doesn’t work, I  can usually hear my team’s voices, “Delegate, DK!”

Staying Positive When Your Product Causes Pain

Sign with words: We Like You Too :).

I make and think about WordPress themes all day with the WordPress.com Theme Team. They control the appearance of a WordPress website, and it’s a heck of a fun job. Most of the time.

What I often hear from customers who use our products: “I just want to get it to look how I see it in my head.” Or something similar. People have a vision, and unfortunately, some levels of customization in WordPress can be hard without advanced knowledge or coding expertise. So ultimately, I can come away from many of these conversations and support tickets feeling like I’ve failed my customers. That’s true to some degree, of course. But how do you keep moving forward, releasing something better for people, if all you see is the negative?

You can’t. I want to share some tips on how to stay positive when your product can cause customers pain.

Search for wins too: My team spends a lot of time trying to detect challenges customers face and how to fix them. Naturally, this leads to a lot of, “Well, that’s terrible. No wonder the customer quit or became confused.” When you’re finding this stuff, look for the positive too. We have a “Random site” button where I can view a random site with a particular WordPress theme on WordPress.com. Sometimes, I look around until I find a nice-looking site, and explore it a bit.

Share the positive: Finding wins won’t help unless you share them. The support staff on our team drops cheerful notes about customers liking themes or features regularly. It’s a small thing, but it makes you feel good. Real good. Any product team needs those feelings in bunches.

Build a culture around finding and sharing the good: If you do this regularly, you start to feel like you’re winning regularly too. And it balances out that feeling that you’re failing your customers when you create something they struggle with. My team could always be better at this, but a few ways to start:

  • Share one win before every weekly meeting.
  • Start and/or keep product testimonials updated. It forces you to find the gold you know doubt have buried.
  • Have a place to collect the positive, and have it be visible so it’s obvious when it hasn’t been updated in a while.

Good luck in the product trenches, and stay positive out there!

Photo courtesy of Adam Jang.

Originally published on Automattic’s Design Flow blog.

Thoughts on Frontend Design

I’ve often said to colleagues that at times I don’t feel like I’m a designer or developer. Most of the time, I feel like I’m right in the middle.

I personally think that people who are skilled at frontend design are in a great position to help bridge the divide between the design and development worlds. They are mortar that help hold the bricks in place.

Brad Frost recently shared thoughts on fronted design, and a front end developer’s role in the design process. It resonated with me in a lot of ways, Besides identifying with the being in the middle of design and development, he points out everyone falls somewhere different in the spectrum. That’s the great thing about being a front ender – there’s so much interesting stuff to do and many ways to find it.

Is Accessibility Hard?

Well, no. And yes. Let me explain.

Every now and then, I see something like this from someone in the web community:

But I’m just gonna be honest here… for most developers, coding for #a11y (especially screen readers) is might as well be voodoo

I get it. I still remember the first time I turned on a screen reader. What a foreign experience! I felt so lost. But remember, when users visit a site that isn’t as accessible as they need it to be, that’s how they feel too. I’m not trying to guilt you into accessibility, but show you that we can all have similar experiences that fuel empathy.

The entire Web can feel like voodoo at times. A blur of fast-paced, “what should I learn next?” – “oh no, I feel so left behind” – “I don’t know this all that well” pile of voodoo. Accessibility is no different than learning anything else. Like responsive design, Sass, React or whatever comes next. You can learn accessibility. That’s the “no” part of my answer to “Is accessibility hard?”

So what’s the “yes” part? Accessibility is hard because you have to take that first step. You have to be willing to try. Feel lost. Make mistakes. And of course, like anything else, the deeper you go – the more complex it all becomes. But then you remember, you know a little voodoo, and you’ve got this.