A brief round up of what I did this year, mainly for myself but you can read it if you want.
Posted in: General
Definition of tabindex from w3.org:
This attribute specifies the position of the current element in the tabbing order for the current document. The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard.
In general you shouldn’t need to explicitly set the tabindex of an element on a page, however there are a few exceptions to this
Today I got a comment on Autoplay is bad for all users which asked:
So why does this high-traffic site designed by a former top-Google UX designer use it?
The comment has linked to a page which has video as a background element playing underneath the introduction text and call to action button, the images are moving but there is no sound on page load. At times this apparently important information is completely invisible.
Using video as a background is on the increase so it’s important to know how to make it accessible for everyone.
For years designers have overlaid labels onto input fields in order to save screen real-estate. As front-end developers we implement this using absolute positioning and event handlers to move the label offscreen once the user has focused into the field. User focuses; label disappears.
The placeholder attribute was introduced in HTML5 and has since been misused in order to replicate the functionality described above. Let me set this out very clearly before we move on, the placeholder attribute IS NOT a replacement for a label.
Just over three years ago I wrote an article called Autoplay is bad for all users. It was written a few months after WCAG 2 became a formal recommendation but before HTML5, particular the
video element, had really gone into mass production.
Much, if not all, of that article still holds true today but there are a couple of points to add to it.
A new domain is born—wai-aria.punkchip.com—a place for me to keep all the great articles and links I found about ARIA.
If you develop accessible websites it’s worth knowing how people will physically interact with them. Most of the software, peripherals and hardware described below are to assist people with visual and motor impairments.
A while ago I wrote ‘It’s not HTML5! But that’s ok’ and then I finished a web standards version of The Guardian’s interactive in order to prove they do not require Flash. So when I saw I had been mentioned on The Guardian website’s technology section I was excited!
As a follow on from WAI-ARIA states and properties: Practical examples, I wanted to write up a bit more of what I’ve been adding to my current project. These examples all fall under how to cope with form validation and giving assistive-technology AT a view of what is going on.
I’ve been trying to include some WAI-ARIA into the project I’m currently working on. Luckily for me I’m using jQuery’s UI dialog and autocomplete plugins and they come with ARIA states and properties straight out of the box! Adding ARIA to my own UI widgets led me to conclude that it’s quite tricky to get right.
Today, the web accessibility community have been getting frustrated with a comment Ian Hickson wrote in reply to a bug report ‘No alternative text description for video key frame’ in HTML5.
The accesskey attribute has been part of the HTML specification for over ten years and its purpose is to give keyboard users a shortcut to access a specific area of the page or to jump to a different page. In HTML5 the accesskey may be used on any element, but do web developers still need to use it?