Monthly archives for March, 2014

It is not uncommon for developers to start marking up their webpages immediately after receiving visual mocks from designers. What this does, however, is that it robs everyone (developers, designers and product analysts) from understanding the content before it goes live. In fact, it’s rather surprising how a lot of organizations, big and small, don’t have a good grasp on their content and it’s semantics. This lack of understanding can lead to a bunch of serious problems:

Illogical organization and flow of the data on the User Interface (UI).

These problems are costly in terms of time and money. So, how can they be avoided? The answer is to design your content, just like you design other parts of your application. What needs to be done as the first step is to examine your content. Users come to your web application for one thing and one thing only; to consume and interact with YOUR content. It would be ill-advised to not examine this content and design “it.”

So, in a nutshell, content-first design is an exercise that allows us to interrogate the content to better understand:

The most important piece(s) of data

The priority of each piece of data in relationship to others

The logical grouping of data to form meaningful objects

The various workflows/scenarios in which the priority might change (does the workflow change when accessing the content on mobile devices vs. desktop?)

If you’re a developer, stop here for a second and ask yourself if you would have written a similar implementation. Be honest!

Now, while this HTML implementation is perfectly valid, it isn’t at all ideal. The main reason for this page’s existence is the search results. Shouldn’t this content (search results section) be front and center? Shouldn’t it come first in the source order? The answer is yes, it should. The filters complement the main content (search results) and, thus, should come next in the source order. So in order for the code to be more semantic, the filters and search results section need to be flipped in order.

As suggested previously, content-first design allows you to question the priority of the data and interrogate the content in a way that can reveal patterns and relationships. The exercise will aid in writing more semantic code and, hence, better visibility/accessibility to screen readers and search engines.

For ideas on how content-first design workshops might be conducted, watch this presentation.

While web accessibility usually carries a specific meaning (accessibility given certain disabilities), I typically think of it in the true sense of the word; making software accessible to as many people, user agents, devices, and machines as possible. To me, accessibility is a design problem that needs to be solved. A problem that isn’t separate from the rest of any application’s architecture. A problem that needs to be approached properly, and planned for thoroughly.

Unfortunately, the reality in which we approach accessibility is a little bit different. I was stumped by one of my colleagues who asked me:

“I hear you talk constantly about accessibility, but man, it’s such a boring topic. Do you really dig it?”

The answer is obvious … I’m blogging about it. So, yes, I dig it. But what was most interesting about his statement is that I actually agreed with him. Let me explain. My colleague’s statement made me realize how poorly, us, web developers approach accessibility. It is, unfortunately, thought of as a task or checklist that gets tacked on at the end to be “compliant” or to fulfill some requirement. How can this not be boring?

But it’s not more boring than writing your unit tests after you’ve implemented your functionality, whatever it might be. It is the same concept. Test driven development (TDD) is fun when you follow its principles; letting your tests guide your design and development of better code. If you do it last, then you’re just fulfilling some “silly” requirement while not reaping the benefit of the approach.

Accessible web applications are not happy accidents. They are a direct result of good engineering principles and solid design put together. They’re based on deliberate and intentional design. So, to produce quality, accessible web apps, we need to change our perspective.

How do we do that? How do we become more empathetic to users with disabilities? I’m glad you asked.

“You don’t need to change peoples’ mind about disabilities, you need to change their minds about themselves.” – Music within.

I love this quote from the movie music within. It reframes the approach to promoting better accessibility practices. We need to start changing the way we think and develop web applications. We need to approach the problem a bit differently. Here are some thoughts:

Before development:

Content-first Design: Understanding the content, it’s priority in the document, the relationship of this content to other companion content, and the grouping of content to form meaningful objects is content design. Additionally, being aware of the various medium and workflows the content might be consumed is important to understanding how your content might be tailored and delivered to varying audiences. For more info on the topic, watch this presentation on how content-first design workshops might be conducted.

Beginning of development:

Progressive enhancement: Starting really simple is the key to having a maintainable and logical web application. For instance, rather than laying out the styles while developing the page, write the flat markup first and see if it makes sense. Progressive enhancement suggests starting from simplicity and then layering in enhancements for more capable user agents.

During development:

Semantic markup: divs have no semantic meaning. There might be some other tags that provide better semantics. For instance, use the html5 header tag for grouping outlined headings or for your site’s header. Use the section tag for logical sections in your page. Here is a link to an HTML5 element flowchart.

ARIA roles: ARIA – Accessible Rich Internet Applications is a spec that helps provide better context to screen readers of rich web apps. ARIA uses landmark roles to describe certain portions of the page. For instance, developers can specify that a header tag is used as a “banner” using ARIA role=“banner.” This aids non-sighted users in quickly understanding the context of the section and, hence, the layout of the page.

ARIA roles also have other atomic values for widgets such as sliders, toolbars, menus and menu items. These are helpful when writing a UI framework.

After development:

Test your application using a variety of different tools. There is a bunch of automated accessibility tools out there that can help.

TotalValidator

AChecker

Juicy Studio Accessibility Toolbar.

Finally, put your site to the test. Learn how to use VoiceOver (a screen reader software) if you’re on a Mac or the Accessibility mode if you’re on Windows. There is also a Chrome screen reader plugin by Google called ChromeVox.

Last but not least, test the usability of your web application with non-sighted users if at all possible.

I hope to elaborate on the different approaches listed above in future posts. I just wanted to put some thoughts out there to, hopefully, get others thinking about the topic.