Posts tagged with “WAI-ARIA”
WAI-ARIA for screen reader users: An overview of things you can find in some mainstream web apps today
After my recent post about WAI-ARIA, which was mostly geared towards web developers, I was approached by more than one person on Twitter and elsewhere suggesting I’d do a blog post on what it means for screen reader users.
Improvements to the handling of the aria-pressed attribute
On Monday this week, Heydon Pickering brought to my attention that Firefox has a problem with the way it handles the aria-pressed attribute in some circumstances. aria-pressed is used on buttons (or elements that have a WAI-ARIA role of “button”) to turn it into a toggle button which can be either pressed or not. Think of the Bold, Italic, etc. toolbar buttons in your favorite word processor as an example.
What is WAI-ARIA, what does it do for me, and what not?
On March 20, 2014, the W3C finally published the WAI-ARIA standard version 1.0. After many years of development, refinement and testing, it is now a web standard.
WAI-ARIA showcase: TinyMCE 4.17
Today, on February 26, the TinyMCE team released version 4.17 of the JavaScript/HTML editor for the web. In the release notes, the first item mentioned is much improved accessibility support. For those of you not familiar with TinyMCE: It is the WYSIWYG (What You See Is What You Get), AKA visual or rich editor used in many popular content management systems such as the WordPress blogging software.
WAI-ARIA showcase: Microsoft Office web apps
Prompted by the recent Microsoft and GW Micro partnership announcement, I took a long overdue look at Microsoft’s Office 365 product offerings. The Home Premium edition not only gives you five installations of full Office Professional versions in your household, Windows and Mac combined, but also the apps for iOS and Android on up to five mobile devices, extra SkyDrive cloud storage space, and access to the Office in the browser offerings. Considering the cost of shelf Office products, the subscription prices are an amazing end user benefit!
Easy ARIA Tip #6: Making clickables accessible
It often happens that designers and web developers agree on the fact that they do not like the standard buttons or the styling capabilities of buttons in browsers. To work around this, they then resort to what’s called clickable text. It is in many cases a simple span or div element with some funky styling that makes it look like a button with some fancy twists. A JavaScript click handler then does the magic behind the scenes that happens if the user clicks on that particular styled text with the mouse.
Sometimes you have to use illegal WAI-ARIA to make stuff work
In this blog post, I’d like to recap an experience I just had while trying to apply some accessibility enhancements to the NoodleApp app.net client.
Advanced ARIA tip #1: Tabs in web apps
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.
If you use the WAI-ARIA role "application", please do so wisely!
This goes out to all web developers out there reading this blog and implementing widgets and other rich content in HTML, CSS and JavaScript! If you think of using the WAI-ARIA role “application” in your code, please do so with caution and care! And here’s why:
From WAI-ARIA to HTML5 and back...or maybe not?
Over the weekend, I gave a presentation at the German Multimediatreff. I talked about how to make things more accessible by combining HTML5 and WAI-ARIA in smart ways, using HTML5 where available and appropriate, and enhancing the user experience where HTML5 still has gaps in the implementation. This is a recap of what I showed.
Apple's iOS 4 supports WAI-ARIA landmarks
This is, I believe, my 100th post on this blog, and I’m using it to announce that Apple’s iOS 4, released yesterday for the iPhone and iPod Touch, supports WAI-ARIA landmark in the VoiceOver screen reader. VoiceOver has had, since its inception, a feature called the rotor. The rotor allows users to set a particula rweb element by which the one-finger-flick up and down gesture moves in mobile Safari and other apps that use a web display. This feature is now highly customizable. Not only can you enable and disable certain features (for example if you never want to navigate by graphics, you can disable it completely and it won’t show up in the rotor). But the rotor settings also include a new feature called landmarks. This rotor setting is disabled by default, but can be enabled through the Web settings sub window of the VoiceOver settings. Once enabled, and the user switches to it via the rotor gesture, navigating by WAI-ARIA landmarks on a page works very nicely. The one thing that VoiceOver does not do yet is announce the type of landmark, be it banner, main, search, complementary etc. Furthermore, the landmarks also include what is called automatic web spots in the VoiceOver on Snow Leopard for the Mac. So not only do you jump to the actually marked up landmarks, but a few more spots on a page Apple deems interesting. In my experience, these usually are quite useful spots, too, so this doesn’t harm the original landmark feature at all.
JQuery UI 1.7 released
The jQuery UI team has released jQuery UI 1.7. Congrats on this release!