Making an important message accessible

Tue, 10 Oct 2017 16:30:00 +0000

With all of the recent hurricanes, wildfires, and other natural disasters, you’ve probably noticed a proliferation of prominent messages at the top of websites directing impacted users to emergency resources. These messages are important and we want our users to be draw to them quickly when they visit our site.

Drawing a user’s attention without annoying them (no alerts, modals, etc.) is fairly simple. We can use large fonts, bold colors, icons, and white space to visually separate the message from the rest of the page and make it noticeable. Unfortunately, this doesn’t apply to users with a vision impairment who browse the web with a screen reader.

So how do we make a message stand out for someone who can’t see all of our smart design decisions? This question came up recently at work when my teammate Rob asked me if there was an Aria role for an important message.

First things, first

Screen readers, like browsers, don’t always follow the spec perfectly and might behave differently. For this reason, ordering content in a meaningful way and using semantic markup should be your first concern. This ensures that a user can move through your document in a way that makes sense, even if an accessibility feature isn’t functioning as expected.

Aria “alert”?

Back to the problem of making an important message accessible, my first thought was to use “alert”, which is meant to be used on “a message with important, and usually time-sensitive, information” or “status”, which is similar to “alert”, but less assertive.

Unfortunately, according to WAI-ARIA Authoring Practices 1.1, “It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes.”

This means we could only use “alert” or “status” if the message is dynamically added to the page after it finishes loading. This feels like too much overhead for a message that we really just want in the page from the start.

Landmark roles

The next idea I had, and the solution we ended up using, was a less common landmark role called “region”.

Landmark roles are used to identify the structure of a web page. Screen readers create a menu out of landmark roles which the user can utilize to quickly jump to major sections of the page.

The “region” landmark is used to contain content that is “relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page.”

We can use the “region” landmark on our important message along with “aria-label” to provide the text that will show up in the landmark menu. Now, if our user is navigating the page with landmarks they will see that there is something important for them to read. On a Mac using VoiceOver it looks like this:

Here is a sample of the code you could use:

<div role="region" aria-label="Important Information">
  This is important information!
</div>

Best solution?

I like this solution, but it’s not perfect. I would rather be able to use “alert” which is supposed to read the contents right after it reads the page title, but the lack of support means I need something else.

This solution makes it easily available without being annoying. If you can think of another solution, I’d love to hear about it!

This article was cross-posted to Medium.com. Leave me a comment over there.

Blog recovery, finally

Mon, 24 Jul 2017 21:20:00 +0000

I mentioned in this post that I would eventually move all of the old posts that I thought I had lost from my original blog to this one. Well, 4 years later I finally did it!

It was a pain in the ass, but there are now 63 posts dating back to September 6, 2006. So, if you’re in the mood for a bunch of posts about hating George W Bush, feel free to dig in!

If you really want to get weird, I restored all of the posts I could recover from my old Xanga blog into a wordpress site.

https://yodasw16xanga.wordpress.com

Have fun!

This article was cross-posted to Medium.com. Leave me a comment over there.

To Fork or Not to Fork?

Tue, 07 Jun 2016 21:00:00 +0000

In 2013 I wrote a CSS framework called Scales. At the time Scales was heavy influenced by another CSS framework called inuit.css by CSS Wizard Harry Roberts. I initially intended to use inuit.css for a project at work, but some of the patterns didn’t work the way I expected or wanted. So, like many unfortunate and misguided souls before me, I decided to create my own framework that worked the way I wanted. Since I really liked the way inuit.css worked in a lot of ways, Scales ended up “borrowing” a few of the patterns. I cleared this with Harry over email and added the appropriate attribution to the files that were either based on or outright copies of inuit.css.

A little over a year later, after using Scales in several projects at work, I began writing version 2.0. One of the biggest issues keeping people from adopting Scales was that it was a single codebase. You either used all of Scales or none of it. For version 2.0 I decided to split each piece into its own Git repository so that the whole thing could be pulled in to a project, or individual patterns could be used.

Around the same time I noticed that Harry was doing the same thing with inuit.css. Since there were still a few patterns that I would be breaking out into their own repo that were copies of what were now their own repo in inuit.css, I decided to just fork those into the Scales org. Since some of the naming conventions and code style were different between the projects, I made the those changes and pushed those repos up as a part of Scales. This seemed like the appropriate thing to do. I figured I wouldn’t really need any specific attribution anymore, because you could see right in the repo that it was forked and linked directly back to the original.

A few weeks ago I had a contribution to a Scales pattern that wasn’t showing up on the person’s contribution graph on Github. While looking into why, I found this rule from Github about what counts as a contribution:

The commits were made in a standalone repository, not a fork.

Github.com

This means that if you fork a repo and make any changes to it, you don’t get any credit for it in your contribution graph or in your contribution history. Learning this made me question the strategy of forking a repo for anything other than contributing pull requests back to the original.

What if a project is abandoned and the owner is unresponsive, but you want to take over the project and keep it going? Until I learned this I would have said to just fork it. I always assumed that was the best practice for those kinds of situations. Now, I would want to start a new repo, copy the old project over, and put a note of attribution in my readme.

Another problem I noticed with this rule relates to an open source project by a former co-worker, Julie Cameron. She is the creator of a pretty popular jQuery plugin called SlickQuiz. When she moved on to a new company, she forked her repo from the official company Github org and has made 58 commits to that fork. The most recent commit was on April 8, but as you can see, she gets no credit for it.

While this says something about changes that my work should consider making to how we treat projects that are maintained solely by someone who has left the company, it also makes me question how Github counts contributions to forks. It’s clear that forking is not only used as a way to contribute pull requests back to the main repo.

Should Github have another process in the UI that is like a fork, but meant to mean “this is mine now and I don’t intend to contribute back”? Should I just not fork things as a way of showing attribution and start standalone repos instead? Am I the only one who thought forking in these ways made sense?

This article was cross-posted to Medium.com. Leave me a comment over there.

This BEM Mistake Has Me Bummed

Tue, 08 Mar 2016 15:00:00 +0000

A lot of people have jumped on the BEM bandwagon in the last few years. I was initially dismissive of BEM because of the rather ugly style, which uses double underscores (__) and double dashes (--) to separate the different parts of the class name. It looks like this:

.block {}
.block__element {}
.block--modifier {}

After giving BEM a fair chance a couple years ago, I became a convert and really enjoy it now. Unfortunately, at work, in articles, and while looking at open source projects, I see BEM used in a way that makes the code less modular and harder to maintain.

BEM started as a methodology for building web applications created by Yandex, but most people who use BEM focus on its CSS class selector naming convention that was popularized by articles from Nicolas Gallagher and Harry Roberts. If you are unfamiliar or want to dig deeper, CSS Tricks has a pretty good BEM 101 article.

How You’re Doing it Wrong

I read an article a few months back that inspired me to add this post to my list of “I need to start blogging again” ideas. The article, Battling BEM: 5 common problems and how to avoid them by David Berner, had the goal of pointing out some mistakes people make using BEM, but seemed to miss what I believe is the most common mistake. It even included the mistake in its example of “The right way”. Take a look:

<div class="card">
    <div class="card__header">

        <h2 class="card__title">Title text here</h2>

    </div>
    <div class="card__body">

        <img class="card__img" src="some-img.png">

        <p class="card__text">Lorem ipsum dolor sit amet, consectetur</p>
        <p class="card__text">Adipiscing elit.
            <a href="/somelink.html" class="card__link">Pellentesque amet</a>
        </p>

    </div>
</div>

Do you see anything wrong here? Let me explain.

OOCSS changed the way I write CSS forever. For me, BEM simply gives me a better way of naming my OOCSS patterns. The problem I have with the example above is that it violates one of the 2 principles of OOCSS: Separate container and content.

This principle was originally described like this:

An object should look the same no matter where you put it. So instead of styling a specific <h2> with .myObject h2 {...}, create and apply a class that describes the <h2> in question, like <h2 class="category">.

Object Oriented CSS

Taking this a step further, you still have to be careful not to write the selector as .myObject .category {...}. This ties the content, .category, to the container, .myObject.

Content should almost never be location dependent. If I like the look of the heading style in my cards and I want to use the same style in a product list, I should be able to do it without writing any new CSS. I should be able to just drop the same class on the heading in my product list and have the same style. Unfortunately, giving BEM style names to our content (in the example above: h2,a,p,img) ties it to this component. This connection may only be symbolic since you could easily use the same class inside another component (as long as you keep your selectors flat), but if you do, you are losing one of the biggest benefits of BEM.

You should be able to essentially work out the HTML structure of a component just by looking at the selectors in your CSS. By giving the content component specific classes you are tying them to that component and making it impossible to work out the structure of the HTML. The CSS for this component would look like this:

.card {...}
.card__header {...}
.card__title {...}
.card__body {...}
.card__img {...}
.card__text {...}
.card__link {...}

When written out as selectors, you could assume that there is a parent with a class of “card” and 6 direct children. Since we have seen the actual HTML, we know that this is wrong. You could get weird and use classes like .card__header__title, but this is the first common mistake that the article (correctly) points out.

How you should do it

When using BEM to name a component, I recommend only naming the structural elements and leaving the content within those elements alone. Define the pieces that are required for the pattern and allow the content inside to be flexible. Here is how I would mark up the card example from above:

<div class="card">
    <div class="card__header">

        <h2 class="heading-secondary">Title text here</h2>

    </div>
    <div class="card__body">

        <img src="some-img.png">

        <p class="caption">Lorem ipsum dolor sit amet, consectetur</p>        
        <p class="additional-info">Adipiscing elit.
            <a class="external-link" href="/somelink.html">Pellentesque amet</a>
        </p>

    </div>
</div>

Giving the content elements inside the component generic names makes it easy to apply the same styles inside any other component. Furthermore, using BEM naming for the structural elements of the component allows you to indicate what type of content belongs in them while still being flexible.

BEM is awesome for creating more understandable, scalable, and developer-friendly names for your components. Don’t let this mistake make your components less portable and flexible.

This article was cross-posted to Medium.com

10 Years

Fri, 12 Feb 2016 11:30:00 +0000

What do you want to be when you grow up? This is a question kids always get asked, and when I was little there was one job I remember wanting. I’ve been told I wanted to be a barber and a clock maker, but the only job I actually remember wanting to do is Architecture. I wanted to design houses and buildings.

I was listening to a recent Shop Talk Show with Monika Piotrowicz and Lara Hogan on the subject of career paths and I started thinking about mine. I realized after looking back on my resume that January 2016 marked my 10th year practicing web design and development professionally. I was inspired to get out the ol’ blogging pen and jot down how I got where I am today.

My current title at Quicken Loans is Senior Web UI Engineer. This is not a title I would have ever dreamed of having in High School, or even wanted for that matter. I got my first computer and 5000 free AOL hours in 1995 as a freshman. I don’t remember why, but I taught myself HTML that school year in 1996 using notepad and tutorials I found on Geocities. I clearly remember friends and family members telling me that I should consider doing this as a career, but I always maintained that I would hate sitting in front of a computer all day. As far as I was concerned, this was just a hobby.

This attitude continued through high school, where I was part of a small class that managed our school district’s websites, and college, where I was studying Mass Communication with an emphasis in TV/Video Production. I continued making personal websites for bands I was in and made a few sites for different academic departments at my school, but it was just fun for me.

My final semester of college, in 2005, I got an internship with Detroit Public TV where I learned that TV production was not the best career to be entry level in with a newborn baby to take care of. I had started doing some freelance web design for extra cash while working at an oil change shop and interning and when the internship was over I kept looking for freelance work.

Since I now had my degree, I began looking for jobs at TV stations in the area. Even though I knew that career was not the best idea, it seemed like my best option to get a better paying job than changing oil. While looking at the job postings for Detroit Public TV, I saw an opening for a “Web Master” position. I figured it was worth a shot and contacted my former boss. I started a job in January 2006 as “Online Communications Coordinator” for the classical and jazz radio station WRCJ 90.9, which DPTV operates.

Now that I had my first real job practicing web design, it didn’t take long to realize that I wanted to do this work for the rest of my life. This job gave me the opportunity and freedom to learn as much as I could. I finally started to understand CSS and moved away from using tables for layout and on to using web standards. I ended up staying at DPTV for a little over 2 years before getting laid off.

My next job, which I started in October 2008, was for a small agency specializing in websites for the industrial manufacturing industry. This was about as exciting as it sounds, but it gave me the opportunity to design new site regularly and try new things. Since it wasn’t a very busy shop, I had a lot of time to get even deeper into web standards and to try new techniques out on my various projects. This job paid very poorly so I was looking for other work when I was suddenly laid off after 9 months. While sitting out in the parking lot preparing to drive home I got a call from a recruiter at Quicken Loans and set up an interview.

I started at Quicken Loans in July of 2009, which is when my career really took off. For the first time I was on a team with a bunch of really smart people who pushed me to learn even more and faster than I had before. From OOCSS to Responsive Web Design to web performance, being at a company that encourages innovation and execution has given me unlimited opportunity to grow as an engineer and a technical leader. I started at QL with the title “Web Developer”, which is basically an entry level position. If I had realized that at the time I might have been offended, but looking back at how much more I learned in my first year at QL compared to my previous 4 years, I really was a novice. The reason I didn’t realize it was an entry level position is because I was never treated that way. My ideas were heard and valued.

Over the last 6.5 years I have moved from “Web Developer”, to “Software Engineer”, to “Senior Software Engineer”. Recently, I had the opportunity to create a new career path focused on the specific software challenges that front-end developers face. I titled the career path “Web UI Engineering” and I am currently a “Senior Web UI Engineer”.

My next step is to get promoted to “Web UI Architect”. Soon I will be able to fulfill that childhood dream of being an Architect, only I will be designing and building scalable user interfaces and design systems instead of houses.

This article was cross-posted to Medium.com

Using Unordered Lists for Forms

Wed, 19 Feb 2014 14:00:00 +0000

I like using unordered lists to mark up my forms. I’m not sure when I started doing it and I’ve never really thought hard about why. A couple weeks ago I got into a debate with a coworker who believes forms should never be lists. If the labels and inputs need anything to wrap them a div is appropriate, not a list. That may be an oversimplification of his argument and I hope and encourage him to write a post explaining his position, as well.

I love debating semantics, so I am glad we got into the discussion we did. It forced me to really think about why I use lists.

SPOILER: I still like using lists.

Forms are a list of questions

My main reason is one of semantics. When we present a user with a form, we are asking them a list of questions. I’m not saying forms have to be made up of lists; divs are also semantically fine since they have no semantic meaning. That said, I can’t think of a good reason not to add additional semantics to a document, as long as they are appropriate.

The ul element represents a list of items, where the order of the items is not important — that is, where changing the order would not materially change the meaning of the document.

W3C HTML5 - Grouping Content

The most important part here is “a list of items.” ul has a very open ended semantic meaning. A bunch of form elements is a list of items. It is a list of label/input pairs. Where using a ul comes in handy over a semantically neutral div is that it creates a relationship between the inputs. When a screen reader comes to a list, it tells a sightless user how many items are in the list. Since I can see, I don’t need this because I can count them. For a blind person, what harm is there in showing them how long the form is?

ul adds useful styling hooks

From a styling perspective, it means I don’t have to apply classes to all of the wrapping divs to target them for default styles. I can put one class on the ul and then add a bottom margin to every child li. That is useful and makes styling easier.

ul creates a coding standard

Also, of lesser importance, it creates a consistent coding standard. It’s any easy markup pattern that everyone knows and doesn’t leave a bunch of ambiguity about where to put divs and how many and around what. Granted, this can be achieved through good project documentation of whatever elements are used.

Do whatever works for you

I certainly don’t believe using ul is the One True Way to mark up a form, but I don’t believe you can argue that it is the wrong way either. It adheres to the spec, adds additional meaning, aids in styling, and is a solid coding standard. Technically, you could probably argue that an entire web page is a list, but you need to draw a line somewhere. For me, it is the point where semantics and ease of use cross paths. When it comes to forms, using ul makes my life easier without doing semantic harm. That’s enough for me.

Silly (Personal) Issue Pushing Jekyll to Github Pages

Wed, 18 Dec 2013 09:46:00 +0000

When I was rebuilding this site to use Jekyll I ran into a really stupid issue when it came to deploying to Github Pages. I had the impression that the master branch (this site is an organization page, not a regular Github page, so the site is deployed to the master branch instead of the gh-pages branch) should only get the code that is generated in the _site directory and that the source should be put on some other development branch.

I spent a good deal of time trying to figure out how to push only the contents of the _site directory to master. I didn’t understand how a popular tool like Jekyll would have nothing about how to do this.

It turns out the issue was my own poor reading of the docs, rather than anything to do with Jekyll or Github. On the Github help page for working with Jekyll it reads:

Every GitHub Page is run through Jekyll when you push content to a specially named branch within your repository...Simply start committing Jekyll formatted files, and you'll be using Jekyll in no time.

Using Jekyll with Pages

All I ever needed to do was push my source files to master and Github would automatically run them through Jekyll. It just works. I completely misunderstood this and wasted a lot of time on hacky and confusing workarounds like subtree merging. I might be the only person who has had this problem, but if not I hope this is helpful.

How to be Extraordinary: Resources for the Discerning Front-end Developer

Mon, 16 Dec 2013 11:46:00 +0000

At work, I participate in a lot of candidate interviews for our open positions. If you do a lot of interviews, you know that the knowledge and skill level of candidates varies greatly. It’s hard to ever quantify exactly what you are looking for in a candidate, but from a technical perspective I think it’s useful to know what an extraordinary candidate would look like. Having this ideal in mind can help focus your questions and quickly determine the technical level of the candidate.

I tend to categorize a candidate’s knowledge into four levels: never heard of it, heard of it, tried it, know it. With this in mind, I started putting together a list of skills that I would want an ideal front-end candidate to have so that I could properly judge their skills.

In doing, I realized that I don’t even have all of these fine skills and I expect that probably no one on my team does either. In all likelihood, you don’t have all of these skills either. This should bother you! You should want to be the best you can possibly be. It’s not about just knowing enough to get the job done. Our industry changes to fast too settle with what you know now.

Take a look at this list of resources and make yourself better!

Articles you should read

The Dao of Web Design - John Allsopp
Responsive Web Design - Ethan Marcotte
Mobile First - Luke Wroblewski
One Web - Jeremy Keith
A Responsive Mind - Jeremy Keith
A Baseline for Front-end Developers - Rebecca Murphey

Books you should read

Responsive Web Design – Ethan Marcotte
Mobile First – Luke Wroblewski
Harboiled Web Design – Andy Clarke
SMACSS – Jonathan Snook
Dom Scripting – Jeremy Keith
Javascript: The Good Parts – Douglas Crockford
Javascript Patterns – Stoyan Stefanov
Learning Javascript Design Patterns - Addy Osmani
Designing with Web Standards – Jeffery Zeldman
HTML5 for Web Designers – Jeremy Keith
CSS3 for Web Designers – Dan Cederholm
Sass for Web Designers - Dan Cederholm

Techniques/tools you should get familiar with

Sass/Compass

Mobile First, Responsive Web Design

Git and Github

Object Oriented CSS

Javasript Unit Testing

Javascript Templating

Vertical Rhythm and Modular Scale

Advanced CSS Selectors

BEM (Block, Element, Modifier)

Performance

Accessibility

A simple new blog

Sun, 08 Dec 2013 02:19:00 +0000

Almost 2 years ago I lost my old blog to a terrible web host’s failure and my own stupidity for not backing anything up. Since then I managed to get around to putting up a new, much simpler site, but replacing the blog has seemed too daunting. With the help of the wonderfully easy Jekyll static site generator, I have finally decided to take on the task.

I hope to primarily write about web development, but I’m sure some other stuff will sneak in. For now, I resurrected a couple old blog posts from Facebook (apparently I had some Wordpress plugin that posted everything to my Facebook notes section) so there would be something here while I work on new content and building an archive from old posts.

I’m not going to go through the trouble of fixing broken links and images on old posts, so please forgive the mess. I just want to get them published for nostalgic reasons and focus on new writing.

I hope you find something valuable here. See you soon!

Who has the conn?

Tue, 13 Sep 2011 13:24:00 +0000

In a meeting, when the discussion about a topic comes to an end and there is some action to be taken, someone will often ask, “Who has the conn?” If you are like me you understand what it means (who is in charge of taking action after the meeting), but you wonder about the etymology of the word. Is it an abbreviation? An acronym? Slang? Or maybe it really is a word on its own? Well, I have an answer for you.

“Conn,” meaning the power to metaphorically steer the course of an endeavor or enterprise, comes from the literal use of that power. When “conn” (in the form “cun”) first appeared in English in the 17th century as a verb, it meant “to direct the steering or course of a ship,” usually from the bridge of the ship or its equivalent. Obviously, the captain of a ship has the primary responsibility for “conning” the vessel, but often delegates the “conn” (the noun appeared in the early 19th century) to subordinate officers. Early battleships actually had elevated “conning towers,” armored to protect the captain, et al., but today the same functions are usually carried out from a “conning station” on the ship’s bridge.

For a term redolent of the high seas and naval battles of yore, “conn” has a remarkably tame origin. “Conn” apparently arose as a variant form of the verb “cond,” also meaning “to direct the steering of a ship,” which in turn derived from the obsolete verb “condue,” meaning “to conduct or guide.” As you might suspect, “condue” itself ultimately harks back to the Latin “conducere” (to lead or guide), which also gave us our modern English “conduct.”

Word-Detective.com