The following article will describe how to properly create accessible tabs in web apps. This is important for both mobile and desktop web applications. Tabs are not native to HTML5, so if you simulate them, you’ll probably use other markup such as lists and list items to generate them. You will have to add WAI-ARIA markup to make these semantically correct. For non-touch-screen interfaces, you’ll also have to add keyboard support manually to make sure the experience is consistent with native apps.
Twitter is often a place of small, but thought-provoking bits of information or personal impression. Just today, Mick Curran, one of the NVDA core developers, tweeted this:
Exactly on this day five years ago, on Monday, December 3, 2007, I started work at Mozilla as the QA engineer for Accessibility. I’d like to take this small anniversary to look back and look ahead.
Last night, I received an e-mail from Jimmy Atkinson, owner of the Web Hosting Database, who informed me that this blog is now listed in the 100 killer web accessibility resources, blogs, forums and tutorials article. I must admit I’m totally blown away by this, and would just like to whole-heartedly thank Jimmy for this recognition!
On October 25, I took part in the 2012 Accessibility Day A-Tag 2012, in Vienna, Austria. This semi-annual event brings together people of various technology fields and organisations as well as end users with disabilities to exchange, share, and get updated on the latest developments in accessibility. This year’s motto was “mobile accessibility”, and with Mozilla’s recent mobile efforts like Firefox for Android and Firefox OS, this was a perfect venue to share and get feedback about our accessibility development and ideas.
There are those days when you watch a discussion unfold on Twitter, and a point is reached where a statement is made that leaves you more or less speechless for a while.
I know, reflections on things usually happen at years-end time, but to be honest, this blog post has been in my head for the last two-and-a-half years, and has thus “seen” a number of year-ends, so I felt that it’s now finally time to put it in writing.
This blog post is once again prompted by something I encountered in the wild. The other day, I was testing browserid.org‘s account manager for accessibility and encountered some inconsistencies in keyboard navigation and screen reader usage. For one, there are “edit” buttons next to the “Your E-Mail addresses” and “Password” headings whose usability wasn’t obvious to me. To my screen reader, the “remove” buttons next to the e-mail addresses linked to my account, as well as the two password entry fields, were visible without me having to actually press these “edit” buttons at all. I could perform all actions without a hitch, so these buttons seemed superfluous and just adding noise. Secondly, even when just navigating through the page via the tab key, I couldn’t find anything that these “edit” buttons could be used for.
Did I ever mention that I love the community, and I love operating systems with truly inclusive design?! Well, now you know! Here’s a little story that took place in the last half hour: