a11y evening ramblings

Responsive Websites and Accessibility Go Hand-in-hand

I have a hard time understanding why sites that promote accessibility do not have responsive websites. It is so hard reading articles when I am getting the desktop version of the site (1200px wide) on 320px wide device.

Focus on the good.

One of my favorite sites to visit is The font size, color contrast for text and responsive nature of the site make it very easy to use on mobile. See. It looks great! But, what is even better, if your on a desktop and you zoom in 250% the site transforms into the mobile version. It’s 100% operable, but it also has the added benefit that it can work for someone that has low-vision. Video demo.

So, if you site is not responsive, you’re missing out on an opportunity to offer low-vision users a better desktop experience AND you missing the boat on mobile traffic. Mobile users have high expectations, if they see the desktop version on their mobile device they don’t even try to deal with it. They just abandon the site. See how going responsive changes that.

Mobile screenshot of's site


a11y web accessibility

Accessibility Implied

As the Americans with Disabilities Act (ADA) turns 25 years old, I am disappointed that the law is still needed to defend the rights of people with disabilities. The ADA author, , recently wrote an article for The Washington Post where he stated, “The ADA was a response to an appalling problem: widespread, systemic, inhumane discrimination against people with disabilities.”

Accessibility benefits everyone.

So, with that law in effect, there will always be ramps or elevators to go along with stairs, braille on signage and other features implemented in every newly constructed or remodeled building since then. Meanwhile, if you look carefully, people whom are elderly, on crutches or pushing strollers (or tired or with their arms full or ect) are using the elevators and ramps too?

These solutions exist, and are available to people not labeled disabled, because they were part of the requirements for the design and development process.

Good commercial construction builders know these  requirements are a part of every build, so doorways are large enough, do not have uneven floor seams and so on. With brand new construction sites, you wouldn’t expect to see someone ripping out cemented steps because the stair rise is completely wrong or retrofitting railings because they were not installed. If they were, they should not be building anything. Am I right?

Process changes: Mobile first

Mobile First Web Design book seen on a phone, ipad and as a hard copy.Not that long ago, there was a huge challenge given to developers and designers to shoehorn desktop sites into mobile sites. So, what needed to happen was for everyone to think about the mobile design before the desktop design because trying to cram the bloated desktop content into the mobile site wasn’t working. We flipped the design/development process, as we knew it, on its head and now we start with the mobile version.

Let’s hit the reset again!

Blue Accessibility IconTrying to retrofit accessibility into a website that never had it is very challenging. Rewriting spans that should have been buttons (or worse, links) and fixing many other common faux pas’ can take a lot of time and resources. The way I’ve been doing it, quietly baking it into each project I’m working on. If we are redesigning the homepage, I make sure the homepage comes out accessible (or the best I can do at the time…I’m still learning).

Wouldn’t it be great if, like a new construction site, we started with accessibility as a normal part of design requirements? And, wouldn’t it be so much easier if we worked from with accessible frameworks? If you know of any that are 100% accessible, please let me know. I am putting my money where my mouth is and giving back by working on the accessibility of open source projects I use (e.g. WordPress).

As we make web content more accessible, it benefits everyone because it makes it more usable: easier to read, use and understand. I see it as an opportunity to create better user experiences for everyone regardless of ability.

I wish we didn’t need laws (or lawsuits) to force accessibility. But, because of the ADA law, we do not expect to hire a construction company just for accessibility features. You just hire a construction company and they should follow the building code laws. The same should apply to the web. Just developers or designers following the web standards, accessibility implied.  Someday. 🙂

Shoot, we still say responsive web design. Isn’t just web design, at this point?

evening ramblings


That moment when the project you have been lovingly/painstakingly working on for several weeks is finally getting it’s time to go live into production. You are both excited and nervous because you’re really happy with the challenges you’ve had to overcome to develop the project and hoping nothing goes wrong with the release.

Lego Movie Meme: Everything Is Awesome!

The code goes live and, for the most part, everything seems fine. A few tweaks here and there will be needed, but overall, the release was a success. Time to pop open the bubbly, right?

Or, so you thought.

Less than 24 hours later, you start getting emails that client has TONS of changes.

What happened? The site looks just like the approved mockups and most of the changes were design related. Make text bigger, bolder, move this, change that. Fine. Ok. Whatever.

Wile E. Coyote's Gravity Lessons

Then, there are changes to elements that took a long time to implement well. Those change requests can take a toll on you. The challenges we have to overcome as designers/developers are what make the job fun and interesting, but it can be a little demoralizing when those solutions will only see the light of day for a week before they ripped out because the featured changed so much. Deep breaths.

Don’t get mad, get some perspective.

Why are these changes being requested now?

Put yourself in their shoes for minute. It might be, that the mockups were last seen and approved 6 months ago OR maybe seeing it live made certain flaws stand out like glaring little sore thumbs. Whatever the reason, maybe a little more communication in the future will help.

Why were features left out of original scope or being removed now?

Stuff happens, no one is perfect. Sometimes the revisions are not as hard/bad as you think they will be. Even if they are worse, does it really matter? Unless you are being overworked, underpaid, treated badly or something along those lines: if someone is paying you to do the work, should you really complain?

Might as well embrace the situation and see it for what it is: an opportunity to overcome challenges that go beyond the code/design. Cheers.

Maybe even grow a little as a person. 🙂

Betty White and Someone else clinking Giant Wine Glasses

a11y web accessibility

The $h!t I Wish I’d Been Told About #A11y

Almost a year ago, I attended JSConf. It was amazing. I left that conference with SO many great takeaways, the biggest and most challenging for me was web accessibility.

For a few days following the event, I kept finding myself thinking more and more about how users that were blind, visually impaired, deaf, motor-impaired and so on would use the thing that I was working on. I was visualizing these people in my head struggling over the the most basic aspects, and suddenly it became real for me. I could see how bad the user experience was and I wanted to fix it ASAP!

But, where should I start? So, I turned to the internets and sought out to find the go to resources for web accessibility.

Step 1.: Audit the site

  1. W3C validate (this will help you fix heading errors, ect)
  2. Navigate the site strictly via tab. Can you tab logically and easily? If not, note where/how/why to fix.
  3. Automated tests. (ATs)
    • I use gulp, so lean towards using gulp-a11y (free)
    • There’s also ($$)
    • I like running updated pages through WAVE. It’s not automated, but, I find the info regarding the errors helpful.
  4. Repeat 1-3 until no more errors. Seriously, do not pass ‘GO,’ do not collect $200. Do not move forward until your site passes these tests.

Some of my gotchas that made it to production for a sprint (or few):

  • The first rule of aria… – It seems as though #a11y newbies (me included) get aria-happy, the ATs will help catch errors here. Another good article on aria: HTML5 Accessibility Chops: notes on using ARIA.
  • Just because you have alt tags, doesn’t mean they are good ones. I had issues with alt text being the same as the text below the image. Sometimes it is ‘ok’ to have alt=” “. ATs will point this out too.
  • Out of order headings h1, h2, h4 … but no h3. 🙁

.: Knowing Where To Go For Help/Info






Some history behind me writing this post. It took me a year to get to the point where I could say, confidently, I know where to look for good info on this topic.

And, here’s what I’d like to call my “Don’t do what I did” list (a.k.a. – chasing your tail around until you’re dizzy):

  1. The w3c – I love you, but I can’t read these docs without a constant drip IV of caffeine and a shock treatment for every time I fall asleep. (Of course I reference the w3c for accuracy, but NOT for how-to’s.) They, also, have a lot of content via the web accessibility initiative, but again…so much content/reading, yet, so few examples.
  2. MDN – In fairness, it looks like there have been a lot of updates here. When I was originally here, there were pages that were like… (╯°□°)╯︵ ┻━┻) f-this. No one can agree on best practices and until they do, we are not dealing with documentation. But, it’s still a cluster-mess if all you are trying to do is figure out how/where to get started.
  3. Finally – I was like… I just want examples!!! Someone, please, just show me some freaking examples!!! So, I went to see what the frameworks (bootstrap/foundation/ect) did for accessibility. Unfortunately, at the time, I was finding nothing, zero, zilch…However, I did find bootstrap plugins and forked repos that were accessible. I was so frustrated to see that these existed, but they were not being brought back to the main codebase:

Things on #3’s front are changing, as well, for the better and you now see some basic info in the docs. They even point out their color contrast flaws.

So, I was running into all these issues trying to find a good place to start. Eventually, I found Marcy Sutton’s article on how to audit a site for accessibility. YAY!

evening ramblings


One of the hardest, yet most important, things I’ve learned over the years is knowing where to get reliable information from.

I remember in college when we used dogpile and askjeeves to try to find the information we needed to design and build webpages. It was so hard to get people to knowledge share in the web community and when they did, it was hard to filter reliable information from the trash. I’ll admit it, at one time in my younger years, I thought the w3cschools was a reliable resource.

Thankfully, Adobe helped facilitate an open and connected community where product users shared knowledge, encouraged and celebrated each other’s accomplishments (and it still does). Flash developers were solid group of people that loved making tutorials and sharing knowledge. But, as we all know too well, Apple killed Flash.

During my Flash dev years, I was fortunate to start learning names of web dev people like Jeffery Zeldman and Eric Meyer. I stumbled upon A List Apart (yep, I still remember the article) and eventually learned of An Event Apart. I attended a conference or two before AEA, but they were nothing compared to that one.

When I attended my first An Event Apart (look at that line up!!!), it completely opened my eyes to what I was missing.

  1. I had finally found my people. Everyone that I met there, whether speaker or attendee, was awesome, humble and nice.
  2. The information presented at it was AMAZING. I immediately joined twitter and started following the speakers and people I met. I was hooked and I still am. I have attended 3 AEAs and counting.

Now, I’m starting to venture out to other conferences such as JS/CSS conf, BD conf, Sass Camp and many other types of conferences. At each of these events, I have met amazing people that open my eyes new and great things.

So, that being said, my #HonoringWebFolk list is the web community. Over the years, I watched it grow and change into something that I am honored to be a part of.

conference sass

Camp Sass Notes (4/4/2015)

Camp Sass was a blast! Thank you to everyone that made it happen! Here are my notes:

Micah Godbolt – Visual Regression Testing

So, what is visual regression testing? It’s pixel by pixel comparison (orig, new, diff).

Variations of visual diffing:

  • page based vs component
  • comp vs baseline
  • headless browser vs desktop browser
  • GUI vs command line
  • extras – css unit testing, scripting libraries

Screenshot Comparison Tools:

1. Wraith

  • Page based
  • comp or baseline
  • headless browser
  • command line

2. PhantomCSS

  • comp based diffing
  • baseline
  • headless
  • command line
  • exras – scripting lib


Bermon Painter – Modular Sass

How do you create scalable websites? Break things down to components!

3 methodologies – oocss, smacss, bem

1. OOCSS – a.k.a. Object Oriented CSS Two main principals, separate:

  • structure from skin
  • container from content

2. SMACSS (scalable and modular architecture for css)

  • base (reset, default typography)
  • layout (headers footers)
  • modules ()
  • states (.is-active)
  • themes ()

3. BEM (block, element, modifier)


Una Kravets – Open Source Design

Innovation/Revolution comes about in tech in (usually) one of three ways:

1. government funding

2. big business

3. open source 


  1. encourage a more open design/dev workflow
    • positive reinforcement #littlewins
  2. foster design participation in the open source community

CARE Method


  • label issues properly (design needed, issue)
  • use a lot of images


  • getting started docs/wikis
  • about doc
  • contrib docs
  • lexicon – terms/def for the docs


  • coordination != collaboration


feedback guidelines:

  • ask, don’t tell
  • be specific
  • explain yourself
  • offer solutions

Jina Bolton – Living Design Systems

Style guides are awesome!!!

Some things to keep in mind:

  • Use a living style guide because it is maintainable
  • Naming conventions – use clarity > brevity
  • Keep properties organized (doc it, and make sure it is easy to know how to follow)
  • Enables rapid dev and testing
  • Elements, components, layouts (modularize, choose your method or create your own variation)
    • types, states, variations



Camp Sass was awesome! Go next year, you won’t regret it!