Women in Technology

Augusta Ada King, Countess of Lovelace (1815—1852), considered by many to be the first computer programmer (of any gender). Portrait by Alfred Edward Chalon.

Lately you've probably heard plenty about education in the US and the renewed push for STEM (science, technology, engineering, math). As STEM education gets attention, it has reminded us all that there is a shortage of women in STEM-related fields as well as STEM-related courses and programs.

As someone in the technology industry, I can see this difference when I go to conferences, when I speak at classes, when I review job applications, and when I talk to women in my life who are interested in technology.

That's why it was heartening to hear about a local young woman spinning up a chapter of Girl Develop It here in Buffalo (also on Twitter at @gdiBuffalo).

I hope this group pans out. I think it can benefit both men and women.

Challenges in Tech

I hate to blunt this positive by bringing in negatives, but it's because of these negatives that I see such value in this new local group.

There are so many pithy, rambling, crazy, angry things on a daily basis about gender in technology that I'd rather not add to the noise. I will, however, link to examples of why I feel there is a need for resources for women in our industry. There are far far more examples out there.

• Nerd Rage Activated: Tomb Raider Reboot


• Dear The Internet, This Is Why You Can't Have Anything Nice

• In tech, some bemoan the rise of 'brogrammer' culture


• "Gangbang Interviews" and "Bikini Shots": Silicon Valley’s Brogrammer Problem


• Women in Tech: Can You Help Find a Few Good Men?

• On Facing Reality


• Speaking up.


• Also speaking up.


• It sucks to be female.


• Speaking up, it's time


• Speaking Up

• Being a good member of the web community


• Playhaven developer fired for sexual jokes after SendGrid marketer outs him on Twitter


• So you’re tired of hearing about “rape culture”?


• A Woman Walks Into A Tech Conference

• PHPness Gate – raising interesting issues

Back on a positive note, there are other resources on the web for women, such as Ladies in Tech, Girls Who Code, and Black Girls Code.

Read More

WebKit Will and Won't Be the New IE

Web developers have been looking to call everything the new Internet Explorer for a while now. With Opera's recent move to WebKit as its rendering engine (replacing Presto), even more developers are suggesting that WebKit is becoming the new IE.

I think they are right, but for the wrong reasons.

How WebKit Won't Be the New IE

nice! opera for android beta includes support for @ supports. AFAIK, the first WebKit-based browser to release with it.

— Tiffany B. Brown (@webinista) March 6, 2013

Unlike Trident (Internet Explorer's rendering engine), WebKit can be wielded in many different ways by many different browsers. It's less a singular rendering engine and more a collection of pieces and parts that can be assembled in different ways. The tweet above demonstrates that there can be different WebKit implementations.

You may argue that the example above is just a case of the first implementation of an update that will make it into all browsers that use WebKit. That may very well be true (we don't know yet), but there are many more examples of differences as Paul Irish painstakingly details in his post WebKit for Developers. I encourage you to read it because it's an almost hilarious dive into the rabbit hole of WebKit. The most salient and clear point is the bullet list of what is not shared in WebKit ports:

• Anything on the GPU
  
  
  
  • 3D Transforms
  
  
  • WebGL
  
  
  • Video decoding
  
  
  
  


• 2D drawing to the screen
  
  
  
  • Antialiasing approaches
  
  
  • SVG & CSS gradient rendering
  
  
  
  


• Text rendering & hyphenation


• Network stack (SPDY, prerendering, WebSocket transport)


• A JavaScript engine
  
  
  
  • JavaScriptCore is in the WebKit repo. There are bindings in WebKit for both it and V8
  
  
  
  


• Rendering of form controls


• video & audio element behavior (and codec support)


• Image decoding


• Navigating back/forward
  
  
  
  • The navigation parts of pushState()
  
  
  
  


• SSL features like Strict Transport Security and Public Key Pins

That amounts to quite a lot of potential variance between WebKit-powered browsers, which is how WebKit is not the new IE.

How WebKit Will Be the New IE

IE10 has been out mere hours, and I already see devs bragging about dropping IE9 support. Do these people build for users or ego?

— Adrian Roselli (@aardrian) February 27, 2013

Far too many developers are always looking for ways to justify testing less. It could be laziness, it could be lack of access to enough device configurations, it could be … well, frankly, I think it's the first one. My IE10 tweet above was based on watching people thrilled as much at taking a shot at Internet Explorer as they were at feeling they could test on one fewer browser.

Developers may use the common engine in one browser as justification for not testing on all the WebKit browsers, or they just may not know about the potential for dramatic differences between implementations. What happens when everyone builds for one awesome browser engine (or one perceived common engine)? We end up with a browser monoculture, devoid of testing for other variations.

As a web developer since the dawn of the web, I've seen it happen before. I remember surfing on Netscape only to find a site didn't take into account my screen colors or resolution, or on Internet Explorer only to find a site didn't take into account my laptop pixels-per-inch default. I was using the popular rendering engine of the day, but the assumption that all users on that engine would all have the same experience was wrong then, and it will be even more wrong now.

WebKit will become the new IE if web developers continue these false assumptions and fail to test other WebKit implementations. Developers will build for one implementation, test for it and maybe a couple variations, and call it a day.

Conclusion

My fear is that all the gains we've made in the last few years toward a more inter-operable standards-based web (leaving behind the Internet Explorer monoculture) will fall away as we unwittingly move toward a WebKit-tweaked yet non-multi-WebKit-inter-operable web.

In short, we'll test for one WebKit, not realize (or care) about all the other variations, and end up breaking the web all over again.

WebKit won't be the new IE, but WebKit will be the new IE.

Read More

Calling QR in Print CSS Only When Needed

For those of us who put together print styles for our sites, we've probably tossed around the idea of embedding QR codes so that users can quickly get back to a page they have printed. In the hardcopy version of my article for .net Magazine, "Make your website printable with CSS," I show how you can embed QR codes in your page (it's not included in the online version).

In my example I use the Google Charts API to generate the QR code on the fly. The problem in my example is that the QR code image gets called whether or not you print the page. Not only is this an additional HTTP request, it's also an additional download that immediately gets hidden. This puts a bandwidth burden on users who aren't printing, but it's also the only way to support your users on Internet Explorer 8 and below (who may be the ones trapped at the office who want to bring the document home).

If you truly have no IE8 or below users, then the less bandwidth-hoggy approach is rather simple, if a bit inelegant.

Since each call to the Google Charts API to get the QR code must include the full address of the page, I cannot leave this to my linked CSS file (which is static, not run through any server-side processing), nor would I want to push every URL for every page of my site into that file. Initially I wanted to use a data- attribute to hold the URL and then, using the generated content feature of CSS, have it take that value and feed it into the content: CSS declaration to have it generate the image from there. Except that's not how CSS works. You cannot use CSS to generate an image from a CSS variable.

The easiest solution is to a put a style block at the top of your page (something I hate doing) and feed the current page's URL into the Google Chart API query string to dynamically draw the image. The rest of the styles that affect placement, spacing, etc. should all be in your print stylesheet already. The example:

@media print {
  header::before
    { content: url(http://chart.apis.google.com/chart?chs=120x120&cht=qr&chl=http%3A%2F%2Falgonquinstudios.com/Engage/Careers); }
}

That's it. Now when (and only when) you call the print styles, the image will load. As proof, here is a screen shot using HTTPFox showing the page before the print styles were called and after, where you can clearly see the QR code is called only when the print styles are fired.

Screen shots of the list of HTTP requests before and after the print styles were fired. You can click / tap to see the full-size image.

Screen shot of the print preview with the generated QR code in place.

Note: This technique will not work in any version of Internet Explorer that doesn't support CSS generated content, which includes IE 8 and below. Internet Explorer 9 and above happily include the QR code generated with this method.

Update: March 26, 2013

I build on this technique to show you how you can use Google Analytics to track which and when pages of your site are printed: Tracking When Users Print Pages.

Read More

Observing Users with Mobile Devices

Nuns taking photos of each other at the Peak on Hong Kong island with their Hello Kitty iPad (which could result in a niche Tumblr).

I had the pleasure of traveling to Hong Kong for the UXHK conference just last week (the conference was the week prior, but I stayed around to be a tourist). While there I decided to spend some time observing how people used their mobile devices and what devices they used. Far from scientific and probably highly tainted by my own assumptions, it was still an interesting experiment.

When I got back I stumbled across some articles discussing how people use their mobile devices and was pleased to find a lot of commonality.

My Own Observations

It seemed like everyone in Hong Kong was using a smartphone. Not everyone was, but given how often my movement on densely-packed streets was stymied because a texting twenty-something or an elderly Bejeweled player was slowly meandering through the chaos, it certainly felt that way.

What I did track is that once on the MTR (the Hong Kong subway), about 8 out of 10 people pulled out a smartphone and started to do something. Occasionally it was someone using it to talk, but usually it was some awkward one-handed wholly-attention-grabbing activity. For the cases where I could see, a bit more than half the people appeared to be playing games. Age did not seem to be a determining factor for games versus non-games. For the remainder, I saw lots of what may have been texting or tweeting. I am guessing this because I primarily saw people selecting Chinese characters as part of some sort of text-based input for an app.

I was most struck by how few iPhones I saw. It felt that most of the people who I took to be locals were using Android devices. I was also surprised at the number of phablets (large smartphones, but not large enough to be tablets) I saw. In particular, every time I looked I saw at least one Samsung Galaxy Note II.

Among tourists I saw a different breakdown. I am guessing who the tourists were, but camera-toting white people seemed an easy fit, with tourist traps, accents, and personal gear helping to suggest others. I saw many iPhones in their midst, and more than a few tourists taking photos with their iPads, Smart Covers dangling in the breeze.

The Apple store in Hong Kong. 5 people were taking photos as I walked by: 1 was using a digital camera, 1 was using an iPad, the other 3 were using Android phones.

How Do Users Really Hold Mobile Devices?

Over at the UX Matters site, Steven Hoober asked How Do Users Really Hold Mobile Devices? His approach was similar to mine in that he and his team observed users "in the wild," but they actually tracked data points as they went (instead of relying on memory, as I did). They get some interesting results in their observations:

In over 40% of our observations, a user was interacting with a mobile phone without inputting any data via key or screen.

The users who we observed touching their phone’s screens or buttons held their phones in three basic ways:

• one handed—49%


• cradled—36%


• two handed—15%

While I don't have numbers from my own casual observations to back up my opinions (they are just opinions, after all), I feel like the breakdown for how people held their phones when using touch input was similar to what I saw. However, I saw nowhere near 40% of smartphone users talking/listening to their phones.

One thing this study cannot capture is how people hold their phones for more specific tasks. For example, I saw lots of people taking photos with their phones, phablets, and tablets. Other than awkward arms-length self-portraits (with either the front- or rear-facing camera), I always saw them use both hands. This doesn't surprise me and it's probably not worth measuring, but it would be interesting if it turned out that my assumption was totally wrong.

Observations on use of mobile devices at airports and train stations

Maish Nichani and Bernie Quah at Pebble Road illustrated some casual observations on use of mobile devices at airports and train stations. While this isn't a scientific study, it's interesting to see that the poses seem to be universal.

For my observations, which were primarily on busy sidewalks, at subway stations and on the subway trains themselves, there would be additional sketches. Even the train sketches don't all apply (densely-packed subways are a bit different than trains with enough room you can sit sideways and that have access to power outlets). I spent far less time observing at the Hong Kong airport because I was either arriving and trying to get clear, or departing and trying to find food.

Your Own Observations

These two articles illustrate how easy it can be to see how people interact with their mobile devices. An advantage to this passive approach is that you catch people behaving as they normally do, without subconsciously modifying their behavior because they are being observed. Anybody who has run any kind of user group testing knows that can be a problem.

A disadvantage to this observational approach is that you don't know what people are doing — you have no context. While you might be able to quickly tell when someone is taking a photo, it's harder to tell if someone is checking in on Foursquare, playing Tetris, texting, tweeting, or looking up directions to a restaurant. This lack of context will always make your observations useful in only the most basic way.

Regardless, these observations might be enough for you to devise your own testing methodology as you build apps, make mobile-friendly sites, develop interfaces in general, or even work on hardware.

Tangentially Related

All those nifty touch-screen laptops have their own interesting challenges. Not only are they touch screen, they are mouse- and keyboard-driven at the same time. Boris Smus shows examples of how user expectations may pan out in Interactive Touch Laptop Experiments.

Read More

UX Hong Kong 2013 Recap

Panoramic view from second row (1st was reserved) at #UXHK. See the check-in at Foursquare.

I had the pleasure of returning to Hong Kong in late February to attend the third (my first) UX Hong Kong two day conference. A combination of speakers, subject matter, my desire to return to Hong Kong, and timing came together to make this conference a good fit.

Day One

Morning Session

The first half of the first day was a series of six speakers (Michael Davis-Burchat, Jeff Gothelf, Timothy Loo, Will Evans, Marcel Takagi, and Josh Seiden) who each had about 15 minutes to seemingly pitch their half-day workshops the following day (for which attendees had already signed up). The benefit for attendees is that they received an overview of each of the sessions and got some of the highlights as a result.

It also felt to me that the conference was taking a decidedly process-oriented focus on UX, specifically around agile, lean, scrum, and related practices.

Timothy Loo spoke about an overall company-wide UX strategy, framing it in examples of business and brand strategies. Jeff Gothelf addressed agile and lean processes and how to apply them to UX. Marcel Takagi spoke about regional experiences in Asia, balancing local needs with universal design. Josh Seiden spoke about how to apply Agile to existing and new businesses. Will Evans introduced me to the Cynefin model, and I think confused some non-native speakers by using "ontologies" and "epistomology" in his presentation. Michael Davis Burchat discussed simplified research and studies to apply reason to the overall process.

Afternoon Session

The afternoon discussion group I selected was "Making a User-Centered Product Company," led by Andrew Mayfield. He started off by having our individual tables (now our group) come up with a definition of "minimally viable product." In fact, for each question he asked, he had our groups come up with definitions and he would simply validate our statements. When he started asking about stand-up meetings, I realized I was in an Agile discussion group (it became clear when I noted that stand-up meetings have existed for decades and he had to qualify that he meant a particular kind of stand-up meeting).

While I felt the session was more about Agile than UX, and the web site did not make any mention of Agile for this session, I had some very good discussions with the folks at my table. Partly because none of them were sold on looking solely at the process. We spoke about what we each did at our jobs and how and what aspects of UX we felt we touched on a day-to-day basis.

Miscellany

For breaks and lunch, there was a nice selection of foods and drinks, even if there weren't enough chairs or tables. Conversations with other attendees were easy, and as the seemingly token American, it was a great opportunity for me to get face-to-face insights on all sorts of software and web topics from the other side of the world.

The post-conference mixer, which I accidentally attended because I just kept chatting with people, was well attended. It helped that it was held in the same atrium as the meal and was the only way out of the building.

During #uxhk mixer, so many folks I met had multinational background—born in one country, raised in another, work in another, etc… Nifty.

— Adrian Roselli (@aardrian) February 22, 2013

Day Two

Morning Session

I attended "Lean UX: Agility Through Cross-Functional Collaboration" by Jeff Gothelf (slides from the same presentation he gave in May 2012) partly because when I signed up I thought it was the only Agile session and I wanted to see how a specific process had been applied to UX. I figured seeing UX in a different way might give me more insight into its application. It turns out with the seemingly Agile focus for the conference, I had already received my introduction to that process.

This session seemed to target the Lean start-up model in particular, which may work well for granular features and products that are well-suited to a two-week sprint cycle. Applying this to a multi-month or multi-year project seems a bit trickier and even Jeff acknowledged that the Lean process may not easily slide into a long-term project or a waterfall model.

During the course of the session, he provided us with a general set of steps to follow and gave us an example product to which we could apply it. The steps were:

1. Goal setting


2. Declare assumptions


3. Hypothesis
   
   
   
   • "We believe that [building this feature] for [this audience] will achieve [this outcome]."
   
   


4. Identify smallest thing to do test that hypothesis (minimally viable product or experiment)

Interestingly, this entire process seems to closely resemble the rapid prototyping approach we have been practicing at Algonquin Studios since the start of the company 15 years ago, itself borrowed from many smarter people before us. When I made this connection in my head, the session ended up applying very neatly to my world.

Afternoon Session

My afternoon discussion group was "UX Strategy: Redesining Business" by Tim Loo (Slideshare of his presentation). Being the last session on the last day, some folks were getting a little antsy to head out, and the session was clearly running over its allotted time, which didn't help. However, when we were focused our group had some great discussions about how to get UX into our existing business models.

The UX strategy Tim presented seemed straightforward, if wordy: "Long-term vision, roadmaps and key performance indicators to align every customer touch-point with your brand position and business strategy."

He presented a general framework for this strategy, challenges to UX acceptance, and then ran us through a "shit-storming" session, where we mapped pain-points for users. In particular we logged an emotion someone might feel when using a product along with what caused it and used those to help prioritize what we would address.

Conveniently, this session wasn't bogged down in a process, but it was a little tricky to understand how to plan for particular outcomes (emotions, customer stories) instead of outputs (features, bug fixes).

Wrap-up

There are some wrap-up pages made up of tweets, pictures and posts. One is Lanyrd's Coverage of UX Hong Kong 2013 and another is Eventifier's collection. Other than Tim Loo's slides, I found no others online. I opted to exclude the sketch notes that popped up because they didn't seem to capture what I thought were the salient points of the presentations.

Read More

Opera: Presto! It's now WebKit

Opera is replacing its Presto rendering engine with WebKit (Chromium, really, when you factor in the V8 JavaScript rendering engine). Big news as of this morning.

If you've been paying attention, it's not really that big or news. About a month ago a video was leaked showing Opera using WebKit (the video has since been pulled from YouTube). Within the last three weeks two of the Opera folks I follow on Twitter are suddenly no longer Opera folks (Tiffany Brown, Patrick Lauke). Heck, even Opera's founder sold off some shares yesterday. If you paid attention, you knew something was up.

All of that aside, what does this really mean?

For Developers

I feel most web developers already ignored Opera. For those developers they can continue to be lazy and ignore Opera.

For Users

The short term impact on users will be minimal. Users will upgrade, users will surf, users may notice some sites work or look a little better.

For users trapped on old Android devices with the Android stock browser (that never seems to upgrade), this could result in a better experience — assuming these users know about and download the Chromium-powered Opera.

For Standards

Opera has an impressive place in the mobile world, being at the top of the pile globally. Opera's participation in the standards process has been valuable, partly because its rendering engine has been used to help move the process forward thanks to early implementations, differences in implementations, and arguments over implementations.

While the standards evangelists at Opera may do a great job of contributing back to Chromium, Google may be the block from those changes being committed. Even when changes get to Chromium, there is no guarantee that they'll make it back into WebKit, which might involve getting past Apple. Only if those changes get into WebKit do they stand a chance of making it Apple's Safari.

From the co-chairman of the W3C CSS Working Group, Daniel Glazman:

For the CSS Working Group, that's an earthquake. One less testing environment, one less opportunity to discover bugs and issues. Let me summarize the new situation of the main contributors to the CSS Working Group:

• Microsoft: Trident


• Apple: WebKit


• Google: WebKit


• Opera: WebKit


• Adobe: WebKit and their own Adobe Digital Editions rendering engine found in many ebook readers


• Mozilla: Gecko


• Disruptive Innovations: Gecko


• HP: has delivered WebKit-based products in the past but is pretty browser-agnostic IMO


• Rakuten: ADE and probably WebKit


• Kozea: WeasyPrint


• Qihoo 360 Technology Co: both Trident and WebKit


• other Members of the Group: I don't know

Suddenly I feel like the US political term lead from behind is apt.

Some other reactions from the Twitters:

It’s becoming clear that WebKit:browsers::MS Word:word processors.

— Eric A. Meyer (@meyerweb) February 13, 2013

And all other engines perished to make way for the best, most popular one.It was called IE6 and the year was 2000…Remind you of something?

— Lea Verou (@LeaVerou) February 13, 2013

Related

...to the news about Presto

• Opera Ice: New browser for Android and iPhone coming February uses WebKit (video), January 18, 2013 from Pocket-lint.


• WebKit is not a cure-all, February 1, 2013 from Tiffany Brown, formerly with developer relations at Opera.


• 300 million users and move to WebKit, February 13, 2013 from Opera itself.


• And Then There Were Three, February 13, 2013 from Robert O'Callahan.


• Strange day for the Open Web, February 13, 2012 from Daniel Glazou.


• Jake Archibald gives his take over at Google+, February 13, 2013.


• Opera switching to WebKit: thoughts and guesses, February 13, 2013 from Peter-Paul Koch.


• The WebKit Culture & Web Rendering Engine Diversity, February 13, 2013 from Robert Nyman.


• I will miss the “Douglas Crockford of browsers” February 13, 2013 from Christian Heilmann.


• One less browser engine, February 13, 2012 from Tristan Nitot.


• Opera and WebKit: a personal perspective, February 13, 2013 from Bruce Lawson (from Opera, the guy who wrote the announcement I link to at the start).


• Hey Presto, Opera switches to WebKit, February 13, 2012 from Ars Technica.


• Devs respond to Opera WebKit switch, February 13, 2013 from .net Magazine.


• Presto Change-o, February 13, 2013 from Eric Meyer.


• Bruce Lawson on Opera’s Move to WebKit, February 13, 2013 from A List Apart.


• Hey -o-, let’s go!, February 13,2013 from David Storey.


• Another chapter of a long goodbye? February 14, 2013 from Charles McCathie Nevile.


• WebKit: An Objective View, February 14, 2013 from Robert Nyman and Rob Hawkes.


• A few folks have asked me what I think of the news..., February 15, 2013 from John Lilly.

...to older bits

• Browser Makers Caving to Vendor Prefix Misuse on this blog, Feb. 9, 2012.


• CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*, February 9, 2012 from Daniel Glazou.


• Reading List – Vendor prefixes, mobile, monoculture by Bruce Lawson, Feb. 13, 2012.


• The iPhone monoculture by Peter-Paul Koch, Feb. 20, 2012.


• Developers focus on the iPhone too much at .net Magazine, Feb. 21, 2012.


• Report on the activity of companies in the WebKit project, February 6, 2013.


• Don't Blame Opera, Blame Devs on this blog, April 27, 2012.

...And evidence that lazy developers can keep on keeping-on (from almost a year ago):

I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.

— Stephanie Hobson (@stephaniehobson) April 26, 2012

Update, February 14, 2013

Since I posted this, some folks have asked just what Opera did that was so useful? This quote from David Storey's post outlines some of it pretty well:

Moving from HTML to CSS based layouts? Opera was perhaps the first to have a useable CSS engine. Håkon (father of CSS, and Opera CTO) often says it was the reason he started to believe a browser could be made in Norway, not just the USA, and joined Opera. AJAX? Opera reverse engineered this from MS’ ActiveX based approach and were the spec editors through Anne van Kesteren. HTML5? Started at Opera with Ian Hickson and others. Responsive web design? Media Queries came from Opera, and were implemented for years before showing up in other browsers. What about native video on the Web? Opera again.

Read More

ARIA Tabs

Last week I spent my Friday afternoon trying to get my head around how to apply ARIA properly to a tabbed interface. I even got so far as to map it out on my whiteboard and snap a photo so I could mull it over during the weekend.

And then the very next day Marco Zehe, responsible for accessibility quality assurance at Firefox, posted Advanced ARIA tip #1: Tabs in web apps and suddenly my weekend of snow shoveling turned into fiddling.

Marco's post included sample HTML for tabs and an outline of how the script to control it should function, but did not include the necessary styles or script to make it behave as tabs. Since I was marking up a tab list anyway to incorporate ARIA, I'm sharing my code here for others to try, enhance, and so on. It's also on CodePen, so you can fork it and fiddle there.

The HTML

My code has minor differences from the example. For instance, I add a return false; at the end of the event handler. I also call the function that activates the first tab at the bottom of the page, so all tabs start as un-selected and no tab panels are visible until that function fires. You can just as easily put the logic into your HTML and CSS to have one pre-selected and skip that function call altogether.

<ul class="tabList" id="tabs" role="tablist">
  <li role="presentation"><a id="tab1" href="#panel1" onclick="showTab(1);return false;" role="tab" aria-controls="panel1" aria-selected="false">Tab 1</a></li>
  <li role="presentation"><a id="tab2" href="#panel2" onclick="showTab(2);return false;" role="tab" aria-controls="panel2" aria-selected="false">Tab 2</a></li>
  <li role="presentation"><a id="tab3" href="#panel3" onclick="showTab(3);return false;" role="tab" aria-controls="panel3" aria-selected="false">Tab 3</a></li>
</ul>

<div class="tabPanels">
  <div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>
    Nulla tincidunt pharetra tortor. In dapibus ultricies arcu. Suspendisse at purus eu est tincidunt feugiat. Praesent et sapien. Vivamus fermentum, diam vel ornare vestibulum, nibh massa imperdiet lectus, eget tincidunt urna urna nec erat. Curabitur interdum. Nam lorem nunc, posuere quis, suscipit eu, hendrerit vitae, nisi. Etiam hendrerit tincidunt felis.
  </p>
  </div>

  <div id="panel2" role="tabpanel" aria-labelledby="tab2">
  <p>
    Vestibulum id eros eu lorem tincidunt sollicitudin. Suspendisse ligula. Sed nisi magna, elementum at, ultricies in, tincidunt imperdiet, quam. Nulla semper. Suspendisse potenti. Sed sollicitudin dolor aliquet purus. Aliquam dui. Proin arcu metus, porttitor eget, pulvinar nec, molestie dapibus, ligula.
  </p>
  </div>

  <div id="panel3" role="tabpanel" aria-labelledby="tab3">
    <p>
      Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam vel erat. Vestibulum egestas purus ut felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
    </p>
  </div>
</div>

<script>
  showTab(1);
</script>

The CSS

This CSS presumes you've already set your typefaces, your page background, and everything works as you want. I have put the minimum styles to make it visually look like tabs. You may notice that I use two different selectors for both a selected tab and for a hidden tab panel. One is by a class name, the other is by the value of the appropriate aria- attribute. Use the first for broader (older) browser support and the latter if you don't care. If you do target just current browsers, then you may adjust the script below to skip writing classes.

.tabList {
  list-style-type: none;
  padding: 0;
  margin: 0 auto;
}

.tabList a {
  display: block;
  float: left;
  border: .1em solid #000;
  padding: .25em 2em;
  margin: 0 0 -1px .25em;
  border-radius: .5em .5em 0 0;
  background-color: #aaa;
}

.tabList a:link, .tabList a:visited, .tabList a:hover, .tabList a:focus, .tabList a:active {
  text-decoration: none;
  color: #000;
}

.tabList a:hover, .tabList a:focus {
  background-color: #ccc;
}

.tabList a.selected {
  background-color: #fff;
  border-bottom: 1px solid #fff;
}

.tabPanels div {
  clear: left;
  margin: 0 auto;
  padding: 1em 2em;
  border: 1px solid #000;
  border-radius: .25em;
  background-color: #fff;
  display: none;
}

.tabPanels div.selected, div[aria-hidden=false] {
  display: block;
}

.hide, div[aria-hidden=true] {
  display: none;
}

The Script

The following script toggles classes for the tabs and the tab panels, as well as adjusting the aria-selected and aria-hidden attributes. There is no keyboard functionality in it at all, but I am always willing to take some from a kind donor. As I noted above, if you use solely the aria- attribute as a CSS selector, you can drop the part that changes the class for each element.

var OpenTab;

function showTab(num) {
  try{
      if(OpenTab!=undefined){
        var OldTabID = document.getElementById('tab'+OpenTab);
        var OldPanelID = document.getElementById('panel'+OpenTab);
        OldTabID.className = '';
        OldPanelID.className = 'hide';
        OldTabID.setAttribute('aria-selected', false);
        OldPanelID.setAttribute('aria-hidden', true);
      }
      var TabID = document.getElementById('tab'+num);
      var PanelID = document.getElementById('panel'+num);
      TabID.className = 'selected';
      PanelID.className = 'selected';
      TabID.setAttribute('aria-selected', true);
      PanelID.setAttribute('aria-hidden', false);
      OpenTab = num;
  }catch(e){}
}

An Example

The following is an embedded version of the tabs on CodePen. Because of how CodePen works, you'll see a few minor differences in styles, but this is at least a functional example which you can fork and tweak.

For example, on CodePen, the function to enable the first tab must be called in the block of script itself, but I prefer to call it at the bottom of the page.

For reasons I cannot figure out, the tabs on the embedded version of this Pen do not work. Visit the tabs directly on CodePen to see them in action.

Check out this Pen!

Wrap-up

That's it, pretty simple. If you have suggestions, corrections, or are a regular AT user and can offer further insight, please feel free to share in the comments or tweet me on the Twitters.

Update, August 6, 2012

Marco Zehe, the guy who wrote the article Advanced ARIA tip #1: Tabs in web apps (which I link above) offered some adjustments to make to my sample code. In essence, dump the aria-hidden from the HTML and use the CSS style visibility: hidden; in its place. His explanation:

@aardrian That would definitely be preferred over aria-hidden, since aria-hidden is not supported by all screen readers.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian Especially older versions of JAWS, which you'll still find a lot, will ignore it.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian So use visibility: hidden; in addition to display: none;, and you should be good. Leave aria-hidden out completely.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

Read More