Never Be Blocked

The worst thing you can do as a professional is nothing

- Bob Martin

"Uncle Bob" Martin is a software engineer and co-author of the Agile Manifesto. About 2 years ago I had the awesome opportunity to see him speak about professionalism. So much of what he said left an impact on me.

Anything other than coding is a waste of my time

- every developer at some point in their career

You're getting paid to code; that's the skill set which makes you marketable, right? Yes, but will your ability to code be enough to keep you at your job? There are millions of software developers in the world, many of whom can probably code just as good, if not better, than you. If you're the King Sh*t of coding maybe writing code really is the only thing you should be doing. Otherwise, consider the notion that there's more to being a software development professional than just blazing through hundreds of lines of code per day.

Besides developers, think of all the people involved in achieving the goal of delivering quality software, on time, within budget, and without surprises—product owners, project managers, delivery leads, sales, authors, curators, designers, marketing, quality assurance, operations—it's a lot of people.

At some point during a project each of the different responsibilities will become a bottleneck. Design assets or content are late because of marketing, the backlog of stories ready to be worked on isn't large enough to keep the team busy, or the QA team is behind by a few weeks which could have an impact on meeting deadlines. What are we developers supposed to do? We help.

Being blocked is unprofessional and irresponsible

- Bob Martin

In some situations we can try to isolate and work around the block like using placeholder images and content. Otherwise, we can help write stories in the backlog to make sure there's a steady flow of available work. We can learn from the QA team to test other developers' changes, and write the automated test suites and load testing scripts. We can even take ownership of lower environments from the operations team. Sometimes we, developers, need to take a break from coding and just kindly do the needful.

Always Be Improving, Learning, and Sharing

I've been a developer for over 15 years. It's fun to think about how quickly the software development world has evolved. I don't ever want to discount anyone's background, including my own—the languages and the tools of the past are part of who we are, and if it didn't kill us, it made us stronger. However, having worked with punch cards typically won't be of any benefit to your career today. Additionally, do not embrace being the sole developer who is capable of supporting something. Creating a forcefield of job security is irresponsible.

It’s unprofessional to have one person on the team that stops a project when they go on vacation

- Bob Martin

Having "Bus Factor" is a grim way to describe how much or little knowledge teams and individuals have about a software's implementation, architecture, and business logic, and what the business impact would be if something were to happen to said individual(s). We need to constantly be teaching others and learning from one another.

One of the most important responsibilities a software professional has (really any professional) is to continuously learn—read books and blogs, practice techniques, teach others (speaking, forums, etc), go to Meetups, build something using new technologies/approaches, or contribute to open source projects. And while having opportunities to learn new things at work happens occasionally, these opportunities alone will not be enough to help us continue to grow at the rate our industry demands. Bob Martin suggests we consider spending an additional 20 hours outside of work on our careers—it's what professionals do. Just as the company we work for relies on us to keep up with our industry and stay on top of our game, we rely on other professionals, such as doctors and lawyers, to do the same.

The people that you work with are just, when you get down to it, your very best friends

- Michael Scott, The Office

This post is not intended to be daunting to anyone. It's more of a reflection of the many great people I've worked with and aspire to be. And while I'm not sure being best friends with all of the people you work with should be your goal, realize they're the people you're with a majority of your time. Have fun, and grow as professionals together.

Further Reading/Watching

If you don't know who "Uncle Bob" Martin is or you haven't had the opportunity to hear him speak, I strongly encourage you to check these resources out:

• https://www.youtube.com/watch?v=zwtg7lIMUaQ
• https://vimeo.com/54025415
• The Agile Manifesto

The Anchor Button: Bad for Accessibility, Bad for Usability

<a href="#">I'm a button, click me</a> — this is the anchor button. Designers and developers have been creating buttons interchangeably with the <div>, <span>, and <a> elements instead of button and input. Who cares—on the surface things look great, right? Well, the easy answer is, wrong—incorrectly using HTML elements is a bad thing, and usually creates additional work to then add the expected default behaviors of the correct elements.

I'll first explain what the spec says about these elements and then I'll explain why following it is important and easy—the HTML 5 specification is actually not that difficult to understand, especially regarding these elements.

The DIV and SPAN

You've probably seen HTML markup that looks like a sea of <div> elements. Here's what the spec says about the <div>:

…The <div> element has no special meaning at all…authors are strongly encouraged to view the <div> element as an element of last resort…use of more appropriate elements…leads to better accessibility for readers and easier maintainability for authors.

The <span> element should be treated with similar consideration:

The <span> element doesn't mean anything on its own…

The Anchor

It's not uncommon to see anchors used like this <a href="#">I'm a button, click me<a/> with some corresponding javascript that will get triggered when the link is clicked. According to the specification, the <a> element should be used as follows:

If the <a> element has no href attribute, then the element represents a placeholder...if [it] has an href attribute, then it represents a hyperlink...[hyperlinks] are links to other resources...

Bad Semantics is Bad for Accessibility and Usability

Buttons and anchors have expected behaviors and states. When you use the wrong elements, these will not be present unless additional work is done to add them.

tab order

<div> and <span> elements are NOT by default in the tab order; button and input are. <a> elements without an href attribute are also NOT in the tab order. Elements typically not in the tab order can be added by setting the tabindex attribute to 0 on that element.

hover and focus states

<div> and <span> elements do NOT by default have a hover and focus state (note: some browsers do provide a default focus state for all elements); button and input do. You can add these states via CSS using :focus and :hover.

click and keypress

Unlike button and input elements, <div> and <span> do NOT by default trigger the associated click event on keypress of both the ENTER and SPACE keys. Additional work will also be required for an <a> element to trigger the click event on keypress of the SPACE key.

assistive technologies

Buttons—or anything else–marked up with a <div> or <span> appear only as plain text to assistive technologies. Also, while <a> elements are treated uniquely, it's common to identify all links on a page using assistive technologies to more easily navigate throughout a site. Therefore, it might be strange having those intended to be used as a button to be mixed up with the other actual links. Any element intended to be a button not marked up using button or input can have the ARIA role attribute set to button—keep in mind, though, all the behaviors/states above still need to be implemented.

Check out this Pen on CodePen to further understand the behaviors/states above. I've also created the a11yButton jQuery plugin that will add the behaviors above to non-button elements.

If it Looks Like a Duck and Quacks Like a Duck...

The simplest rule of thumb is to just use the right HTML elements for the content. Realistically, this is not possible 100% of the time—just remember, when using the wrong elements keep in mind there are behaviors and states that may be expected that will need to be accounted for.

Test-Driven Development Has You Covered

Most of us have probably been left to deal with software that at some time in history was loved by all. The business praised the developers on the team for building it so quickly, and the team felt pretty awesome—they were rock stars. Now we need enhancements, bug fixes, and better performance. Unfortunately, no one from the original team is around, and other developers are scared to touch it, because there are no tests, the architecture and design are overly complex, and understanding where to start seems impossible. What was thought to be a great success is now considered an epic fail. Software development isn't just about building something that works, it's also about building something that can be supported and maintained by everyone.

I'm very fortunate to work on a team that understands the importance and embraces things like pair programming and test-driven development (TDD). These are things, however, that you need to re-learn occasionally to make yourself and your team stronger. TDD is not new—in fact it's about 15 years old. Don't fear, practicing it doesn't make you a dinosaur. It's a technique that drives simplicity in your software and creates a safe environment for you and the rest of your development team.

What TDD Isn't

Sometimes TDD is misunderstood. It's not Test-first development, which suggests that all tests are written before the actual implementation. TDD doesn't mean writing tests after the implementation code has been written. TDD does not mean writing a test for every method of every class.

What TDD Is

TDD is a technique and a tool used to develop software by following the strategy of red, green, refactor—write a failing test against a public API that supports a small portion of business functionality, write just enough code to pass the test as fast as possible, and then refactor the implementation to ensure standards in design and quality are met and to remove any unnecessary code that doesn't support the business need (i.e. no anticipatory design...when you do this, you're spending your company's money or your customer's money on something they don't want).

TDD and Continuous Integration

There are many ways an application can be tested—all of which should be automated in a Continuous Integration (CI) environment. Could all of your functionality be tested using full system integration tests or automated web testing? Sure, as long as you don't mind waiting several hours to find out you broke something.

The goal of CI is to inform developers as soon as possible when bugs have been introduced to the application. TDD creates small, isolated unit tests that are intended to run in a very small amount of time. You still need system integration tests and automated web tests, but they should mainly be put in place to verify everything has been configured and/or wired up correctly—there should be little to no overlap across the different layers of automated tests.

100% Code Coverage...Are You Sure?

There are many tools to choose from that will help you determine how well your code is covered by your tests. Unfortunately, many of them won't tell you the quality of your tests. I'll demonstrate how TDD code coverage is different from non-TDD code coverage.

The code being tested is the AwesomenessCalc function shown in the Awesomeness Calc fiddle, which will tell you how awesome you are. I test-drove this code in the TDD Jasmine spec runner. I'm using Blanket.js to display the coverage in the spec as I'm developing. As you can see all tests are passing and the code is 100% covered.

Now let's pretend to write the non-TDD Jasmine spec runner after all the implementation code has been developed. All tests are passing and it also appears that the implementation is 100% covered. However, it's not fully covered—lines are getting executed by the spec runner, but the actual expected behavior is not being tested. You can also play with this non-TDD fiddle to see for yourself.

Nobody's Perfect

To understand and appreciate TDD in greater detail, I highly recommend watching Ian Cooper's talk "TDD, where did it all go wrong". It's a great reminder that you'll probably never get this 100% right, and how important it is to occasionally listen/watch something like this and reflect on how you currently do things.

One of Many Reasons WAI-ARIA Is Awesome...More Semantics

Accessible Rich Internet Applications (WAI-ARIA) is now a W3C recommendation, so it's important web developers start to understand what it is and how to use it. Also, there's something awesome about WAI-ARIA. Not only does it benefit people using your site, it benefits you as a developer—it provides you with an arsenal of semantic attributes you can target in your CSS and javascript.

WAI-ARIA in a Nutshell

Assistive technologies rely on and take advantage of HTML built using semantic elements appropriate for the content, like nav, header, main, button, ul, and dl—they provide people dependent on assistive technologies the best possible experience. However, even the best markup can't always adequately describe the content and/or its state on a web page. WAI-ARIA allows you to add more meaning to existing HTML markup with roles and their supporting states and properties—there are over 100 combined, including:

• tree
• banner
• group
• aria-live
• aria-expanded

Your HTML Markup Just Got More Meaningful

Consider the HTML markup for a tree made of nested lists and toggle controls. The markup would look something like this (if you already know something about ARIA, pretend you don't):

<ul class="tree">
  <li class="tree-item parent collapsed">
    <ul class="sub-tree">
      item 1
      <li class="tree-item">item 1 child 1</li>
      <li class="tree-item">item 1 child 2</li>
      <li class="tree-item">item 1 child 3</li>
    </ul>
  </li>
  <li class="tree-item">item 2</li>
</ul>

There's really nothing wrong with the HTML above. Using ul and li elements instead of a bunch of div elements is great, because ul and li elements should be used to build a list of items. Also, the class names are meaningful. However, classes like tree, tree-item, and collapsed don't follow a spec and won't be consistently used from site to site where tree controls have been implemented—WAI-ARIA can help solve this problem. WAI-ARIA allows you to develop markup that looks like this:

<ul role="tree">
  <li role="treeitem" aria-expanded="false" aria-level="1">
    <ul role="group">
      item 1
      <li role="treeitem" aria-level="2">item 1 child 1</li>
      <li role="treeitem" aria-level="2">item 1 child 2</li>
      <li role="treeitem" aria-level="2">item 1 child 3</li>
    </ul>
  </li>
  <li role="treeitem" aria-level="1">item 2</li>
</ul>

Most of the Classes Are Gone—What About My CSS?

You don't need classes to style your markup. Target your HTML elements, and target the WAI-ARIA roles, states and properties using the attribute selector. For example, you could style the markup above as follows (from my LESS sheet):

ul[role="tree"] {
  list-style-type: none;
  &:focus {
    outline:1px dotted #0000ff;
  }
  li {
    list-style-type: none;
    &[aria-selected="true"] {
      color:#0000ff;
    }
    &[aria-expanded="false"] > ul {
      display:none;
    }
    &[aria-expanded="true"] > ul {
      display:block;
    }
  }
}

See It In Action

Too see WAI-ARIA in action check out the a11yTree jQuery plugin. I built it, because I wanted to learn more, and didn't quite like the other available tree plugins. HTML semantics with WAI-ARIA is important to ensuring the best online experience for everyone. Finally, if you're a craftsman you should take pride in this stuff just as much as everything else you do—HTML is code, too.

Usability First

Mobile-friendly and accessible are 2 ways that many companies, product owners, and developers would love to describe the sites they build and contribute to. Usually, this is achieved by some form of remediation project, or 2 big epic stories in the backlog near the end of the list of priorities. To be fair, having the remediation project is sometimes a necessary evil; especially, if the site is at least 4 years old—the internet has changed a lot. For new projects, however, having an epic in the backlog for mobile strategy or accessibility is really an indicator of a growing problem the remediation project should also be trying to solve—a site that has some major usability problems.

What Usable Means

I recently read a post titled F*** You by Brad Frost. While I don't agree with everything Brad has to say in the post, it's a great read to remind all of us contributors to the web that not everyone is using an iPhone or the latest version of Chrome on a Mac to view our sites. Ultimately, you're most likely part of a business trying to make money so it's important you know your users and the technologies they're using—you can't make everything perfect for all variations of browsers, operating systems, and other technologies. However, if things like accessibility and mobile experience aren't even the smallest part of everything you do, you're building something that for some users is not usable.

Slice Things Horizontally

An old friend that's a very talented tattoo artist reached out through her network asking if anyone could help update her list of appointments on her web site built using Virb. The template she was using was simply listing all of her appointments in a 2 column list. Her goal was to make things a lot easier for her clients to look up their appointments, which are commonly made far in advance. She wanted a calendar view, which I agreed was a good idea, except that I didn't think a calendar view would be really usable on smaller mobile devices. I also wanted to consider users with disabilities.

So, rather than focusing on the mobile experience, or picking apart every aspect of a calendar with an accessibility lense, or simply trying to make the best damn looking calendar a tattoo artist could ask for—these are all vertical slices by the way—I decided on the amount of effort I'd put into updating the UI, determined the required features, and sliced up the work horizontally. For example, the current interation:

contains a calendar view

nothing fancy here; just your normal calendar arranged by year and month with days of the week headings

is usable on mobile devices

on any device smaller than an iPad, the calendar view switches to a date book view with only dates containing appointments—no frameworks, just simple media queries

addresses some accessibility concerns

the calendar uses a good heading structure, color contrast ratio is verified, aria-hidden used on days with no appointments, and each date read by screen readers contains the month, day of the week, and day of the month

Future iterations can be used to enhance the design, focus on specific mobile devices, or improve the navigation throughout the calendar to improve the experience for all users, including those with disabilities.

Check It Out!

You can see a snapshot version of the calendar at http://theaccessibleweb.com/examples/appts/index.html. I'd love questions, comments, and especially criticism.

There are a couple things about the demo I'd like to note based on some great questions and feedback from Dennis Lembree of Web Axe. The calendar is dependent on javascript being enabled—Virb heavily uses javascript templating; additionally, it was desired to keep the data entry process unchanged. Therefore, the calendar works by reading the DOM, building a new javascript object for the appointments, and rewriting the DOM. Based on the the feedback, I made sure that if javascript is disabled, the old DOM is visible along with a message to let users know the page is better viewed with javascript enabled.

Keeping Things Simpler with Web Analytics

Ace Frehley, Peter Criss, Paul Stanley, or Gene Simmons probably come to mind when thinking of KISS—what about Kelly Johnson? No? Kelly Johnson was the 20th century aircraft engineer who coined the KISS principle/phrase Keep It Simple Stupid.

The principle suggests that systems perform best when they have simple designs rather than complex ones. Today, it's commonly applied to software design and implementation. So, whether you've heard it several times during your career, or are hearing it for the first time, it's a concept that should help keep you and your team focused and effective.

Web Analytics

One way to keep things simple in your web site/application is by knowing how people use your site—the combination of browsers, operating systems, and devices being used to access your site, and where traffic to your site is coming from. Having this information allows you to understand and focus on what really matters to your users—the things you should be spending money, time and effort on.

The mainstream collection of web analytics has been around since the mid 1990s, so I'm not delivering any earth shattering information. However, there are still many people who contribute to the web that either have never heard of web analytics or have implemented web analytics and aren't benefiting from the collected data.

Google Analytics is the most popular web analytics tool, and it's free. It's what I've used to gather the following 21 week snapshot of data for one my sites that focuses on web accessibility, http://itstiredinhere.com. Although, the data below represents the most basic features many web analytics tools offer, it's data that can really help with prioritization.

What combination of browsers and operating systems do I need to support?

This is the question most developers are scared to ask their product owners with fear the response will be, All of them! This answer is usually either too open-ended or not well-informed.

The operating systems your users are using probably won't be that interesting or surprising—especially, the top 3. I've got usage data for 7 different operating systems and 32 different OS versions. Supporting all of them would be silly since the top 9 versions make up 93% of the usage. Here's a breakdown of the top versions of the top operating systems used by people accessing http://itstiredinhere.com:

OS Versions	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Lion	31	35	28	12
Mountain Lion	9	8	11	14
Snow Leopard	2.5	3	.7	3.9
Maverics	.75	N/A	N/A	5.8
Windows 7	21	16	22	42
Windows XP	4	6	3.4	.7
Windows 8	2.5	2	3	2
iOS 6.x	12	15	9	1.3
iOS 7.x	.7	N/A	2	4
iOS 5.x	.2	.2	0	0

The overall percentages might seem to describe your users. However, I've broken down the data into 7 week intervals to help find trends, which can sometimes prove to be more valuable than just the overall numbers. Here are some trends in the data that might be worth following:

• Mountain Lion usage increased, while users using Macs with Lion installed decreased. Overall, it's always nice to see outdated software use decline. I expect to see Snow Leopard, Lion and Mountain Lion usage continue to decline with the free release of Mavericks, which can be upgraded from all 3 of the latest OS X versions.
• Windows 7 usage increased, while Windows XP declined. The decrease in Windows XP is especially exciting, because it's an old operating system that supports old versions of Internet Explorer. Support for Windows XP is ending on April 8, 2014, so its demise is inevitable.
• iOS 5 usage has basically fallen off the map, while iOS 7 looks like it could to be taking over. The data for iOS versions is a good example of why looking at the overall data could be misleading—iOS 6 looks like the dominant iOS version, but its usage significantly declined since iOS 7 was released.

While the days of box model CSS hacks are gone, mixed support for HTML 5 and CSS3 cause most of the cross browser support headache today. A top contributor to this problem is the continued use of older versions of browsers, so you can't do things like blindly upgrade to jQuery 2.x if you've got a substantial number of users still using IE 7 or 8. Out of 12 different browsers being used to access my site, here are the top 4:

Browser	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Firefox	41	46	33	31
Chrome	33	26	41	43
Safari	13	14	12.8	11
IE	6	6.5	5.4	7

While Firefox and Chrome frequently get updates automatically, it wasn't until last year that Microsoft started silently upgrading IE. Along with the fact that major version upgrades are sometimes dependent on the version of Windows, users are still using IE 7 and 8, which are 7 and 4 years old respectively. The same versions of IE can also act differently in different versions of Windows. Here's a breakdown of the versions of IE used to access my site, and the versions of Windows they're running on:

IE Version	8	7	XP	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
10.0	x	x		3.6	3.5	3.4	4.5
8.0		x	x	1.2	1.4	1	.7
9.0		x		.8	.8	.3	2
7.0			x	.7	.9	.7	0

One of the interesting things about the data above is that IE 8 is used more than IE 9. IE 8 was bundled with the release of Windows 7, and unlike IE 9, IE 8 is supported by Windows XP, which after over 10 years is still one of the most popular operating systems today due to its ease of use and lack of bugs. Fortunately, the drop of Windows XP support could mean a huge decline in IE7 and IE8 usage over the next year. So, based on my data, I'll only spot check the earlier versions of IE, especially versions 7 and 8.

We've got to have a mobile experience!

A quality mobile experience has become a necessity for web sites and applications. Unfortunately, many companies don't know where to begin and how to define scope. Whether it's mobile first or not, one popular approach is to implement a responsive design—and it's got to look good on all devices, right? Most likely not.

Web analytics will not only help you figure out which devices to focus on, but will also inform you how important a mobile experience is to your users now and how it might be trending in the future. Almost 20% of the people coming to my site are using a mobile device, so investing in a mobile experience is important, but knowing which devices they're using is important. A total of 13 different devices have have been used to access my site—here's data for the top 3.

Device	Total User %	Weeks 1-7	Weeks 8-14	Weeks 15-21
Apple iPad	9	11	7	3
Apple iPhone	4	5	4	3
Samsung Galaxy S3	3	3	5	1.3

Whether you decide to use a responsive framework or do all the CSS media queries and scripting yourself, you'll soon realize that it's easy to get carried away with trying to make your site look perfect in every device. I'll focus on the top 3 devices devices for now, and continue to keep an eye on my mobile traffic.

Traffic

Knowing from where people are accessing your site is important. 35% of my traffic comes from another site. Here's a breakdown of the top 8 of 31 referring sites:

Referring Site	Referred Traffic %
Twitter	29
Google	27
blog.paciellogroup.com	11
itstiredinhere.blogspot.com	8
webteacher.ws	7
Facebook	7
webaxe.org	5
webaim.org	5

If your site is public, the more ways your site can be accessed online plays a major factor in search engine results prioritization. Additionally, you can use referring traffic data to forecast/prioritize. For example, your site will most likely not be the next Facebook, Google, or Twitter. However, if these are some of your top referrers, it's in your best interest to understand what's trending with these sites, like mobile usage.

Remember, the simpler the better

Web analytics can be free, easy to implement, and can offer a lot more than the data above. As you familiarize yourself with the data, you should begin to realize how powerful it is. If something isn't important to your users, it shouldn't be important to you—it shouldn't be something you spend a whole lot of money, time and effort on. Don't forget to Keep it Simple Stupid.

Tools/Resources

• Learn more about Google Analytics
• VirtualBox is a nice tool for cross-platform testing
• Download Windows/IE VMs for testing
• Use the Dimensions Google App for responsive design testing

HTML 5 Semantics and Web Accessibility: Heading Structure

Has a designer or developer ever tried lecturing you about why you need to be using proper HTML semantics? If so, did your mind start to wander about 30 seconds into the lecture (is it starting to wander right now)? Do you read the HTML specification to help you fall asleep at night? As long as your site looks good and is maintainable, no user is ever going to know or care if your markup is semantically correct.

Actually, some users with disabilities will know if you're not, they depend on it, and probably can't use your site if you're not using clean, valid, and semantic HTML. Having valid semantic markup helps your site avoid many common accessibility issues. However, in some cases the HTML spec offers several different implementation options or is simply unclear. In these cases thinking in terms of accessibility can help provide direction.

HTML Headings as "Defined" by the Specification

The <h1> - <h6> heading tags are among the most useful and important HTML tags regarding semantics. They define the overall structure of the pages in your site. I hesitate to say they're also among the most misused tags, because the HTML 5 spec is a little ambiguous.

Web Accessibility and Headings

WCAG 2.0 has 2 main guidelines specific to headings. In a nutshell, your content needs to be logically organized into sections. These sections need to have headings, and the headings need to represent/identify the content they're associated with.

To further understand the spec and how thinking in terms of web accessibility can help, check out HTML 5 Semantics and Accessibility: Heading Structure.