Am I too SASSy? Should I be Less?

Our parents' (or maybe grandparents') generation in the US have a little game they used to play - something I like to call "what you were doing when...". Of course this was before we were bombarded constantly by news outlets - back when breaking news was covered simultaneously on all three television channels and on the radio stations.

What do you mean "what's a radio"?! Now, that's not funny.

Several generations have played this game - "what were you doing when they announced the war was over", "what were you doing when Kennedy was shot", "what were you doing when Nixon resigned", "what were you doing when Reagan was shot", "what were you doing when the Challenger exploded", "what were you doing when..." - and everyone had their own "what were you doing when" event.

There's a philosophical discussion to be had here regarding καιρός and χρόνος - but that's best served in another venue at another time...but I remember when CSS became a thing, just like I remember when JavaScript became a thing.

Yes, I am that old...but seriously, the reference to three television channels and listening to radio didn't give it away?!

I remember when CSS became a thing, and it was glorious. It was glorious until we figured out that we had to specify everything, multiple times. Suddenly people who were used to writing code couldn't use variables...they just didn't exist. Then, around 2006 someone invents Sass and a few years later we see Less...and CSS preprocessors start moving across the web development world. We combined those wonderful tools with OOP concepts to get OOCSS (thanks to Nicole) and then came BEM and a bunch of other stuff. Seriously, who can keep up with all the abbreviations and acronyms these days?!

Here's what we lost with all the power of preprocessors, though - simple validation.

Sure, there are things like sass-lint, but they're generally geared to keeping developers from making simple mistakes...like using O instead of 0 in a hex value, not actual design screw-ups that not only give a definite impression regarding your ethics and what you value but can cost your organization millions. So your first "take-away" from this should probably be "check your linters to make sure they're covering accessibility as much as they can".

Being that nearly every company I've worked for in the last 10 years has moved to using a preprocessor, I decided it's time to write a rule for at least one of the linters that will check known, common accessibility problems (it's still in progress), and wow is it complicated.

Let me be clear - accessibility in CSS isn't complicated, the preprocessors make it that way. Linter rules are mostly written in JavaScript, which is a skill all good UI engineers should have in their toolbox. I've written linter rules before - I have several on my fork of csslint, in fact, and one of those is a pretty simple accessibility check, but linters for preprocessors - like sass-lint - use parsers that are significantly different than the parser written by Nick Zakas. When I settled on my first "preprocessor" rule being a rule for sass-lint (accessibility-issues), I found that navigating the Gonzales-PE parser gave me fits, until I noticed the Gonazales-PE Playground. Here's the second take-away: find a way to get insight into the object the parser creates - it will make a world of difference.

Now that I know, for instance, that the Gonzales-PE parser builds a ruleset object that contains both selectors and blocks, and that the block object contains declarations, I know how to tie a specific declaration to its selector ancestor.

From there it's pretty easy to eliminate pseudoelements (which are a different accessibility problem than "normal" elements can be) and check the normal elements for common accessibility issues - background color being specified without color also being specified, luminance contrast, content that's made inaccessible a number of ways, default visual cues (like outline) being overwritten, and text being too damned small.

You can see what that rule looks like in my github sass-lint repo for the time being - I don't know if, or when, the rule will be added to the official linter.

Are there ways to improve accessibility with your CSS even though you're using a preprocessor? Yes! (A general clue here - mixins and partials can be a big help.) Unfortunately, you're probably never going to find the answers to problems you don't know you have, so fork your favorite linter and build a rule.

Happy coding.