Ever since I joined Twitter in March of 2008, at my first CSUN under the Mozilla banner, Twitter’s own web presence was always a bit, or even a lot, of a challenge to use for me as a screen reader user. While the initial version was still pretty straight-forward, as time went by and Twitter added more features and turned their web presence into a web app, the interaction became increasingly cumbersome. Fortunately, there are clients on various platforms that allowed me to access the service without having to rely on the web site. Even after the more strict API 1.1 roll-out a year ago, this situation hasn’t really changed for me.

A few months ago, I learned that Todd Kloots had joined Twitter. I knew Todd from when he was still at Yahoo! doing awesome things for web accessibility there. As time went on, members of the accessibility team at Mozilla, the NVDA developers, and Todd discussed various aspects of web accessibility, making it apparent that something good was happening at Twitter!

A few weeks ago, after a couple of tweets by Todd and others, I tried out the Twitter web app for the first time after a long while. And as was hinted in the tweets, the J and K keys suddenly started working much more nicely with the various browser/screen reader combinations I tried.

Yesterday, now, a post was published on the Twitter blog detailing some of the recent changes in accessibility of twitter.com, and an official accessibility team Twitter account was also announced. You can find the team at @a11yteam, and they welcome suggestions for further improvements.

If you are blind and want to try things out, you can do so right away by logging onto Twitter and reading your timeline. J and K will move you up and down through the timeline. Further keystrokes are available if you press the ? (question mark) key. Just remember, if you’re on Windows, you’ll have to turn off virtual cursor mode to be able to properly use them, as they will most likely be captured by the quick navigation key system of your screen reader otherwise. If you’re on the Mac, you do not need to do anything special.

I hope that Twitter will also pay equal attention to detail in their mobile web app, so the app you can get from the Mozilla Marketplace for both Firefox for Android and Firefox OS will be equally accessible. First signs of improvement are there, with tabs and buttons properly labeled nowadays. In addition, starting in Firefox 25, we have improved the way we execute touch events from within TalkBack and Firefox OS, so interaction should be just smooth!

This is exciting news, and I wish the Twitter accessibility team all the best in their future work on the web and native applications! As far as the web and mobile web presences are concerned, we at the Mozilla accessibility team will be here, ready to help wherever needed!

Firefox 25 for Android, out as an official release end of October, and on the Aurora channel since August 9, will include a number of new features for visually impaired users. This continues a series of new features introduced in Firefox 24, which I blogged about earlier.

New reading order

As hinted in my blog post about Firefox 24 new features, we have now made a change to the default reading order of web elements. If you did not make any adjustments, you will get this new reading order as soon as you update to Firefox 25. Now, the current item’s label is spoken first, followed by its role and states, and any changed hierarchical information is now appended at the end. This allows for a much more efficient browsing experience in our opinion.

If you want to change it back, follow the steps given in the other blog post.

Support for landmarks

Firefox for Android now supports landmarks. It speaks the landmark that you just entered, and an option has been added to the three finger swipe up and down menu to move by landmark quick navigation. If you use a keyboard, the quick navigation key is d and Shift+d, similar as in the NVDA screen reader for Windows.

Support for data tables

Firefox for Android 25 supports data tables. If you enter a data table, column and row headers are spoken, if a cell spans multiple columns or rows, this is also announced, as well as the table dimensions and any caption and/or summary, too. When traversing a table element by element, only the necessary information that changed is read. So if you move from column 2 to column 3, but stay within the same row, the new column header is read, but the row header is not repeated. Likewise if you stay in column 3 and move to the next row, the new row header will be announced, but the column header will not, because it did not change.

Suppression of layout tables

Firefox has had a heuristic to determine if a table on a web page might be there solely for layout purposes. While not encountered very often nowadays, it still happens occasionally. Now if such a layout table is encountered, Firefox will suppress speaking of any table or table cell information as to not flood you with unnecessary information.

Speaking of additional information, if available

Sometimes, web authors provide additional information via the title attribute, an aria-describedby statement or some other means that is not the primary label or text for an element, but which, on the desktop, becomes visible when hovering the mouse over the element. This information is stored for screen readers in something we call the AccessibleDescription. Unlike the AccessibleName, which is the primary label or text, you can think of the AccessibleDescription as an addendum. Since there is no real concept of an AccessibleDescription in Android itself, we made a compromise and add this AccessibleDescription if it is there, and if it is different from the AccessibleName. Some web authors unnecessarily put the same text of a link or image in the title as they do in the enclosing text or alt text respectively. We detect that and suppress the redundant info. But if there is true additional information, it will now be appended to the name in the now default reading order. In the old reading order, it will be prepended, since it will honour the setting.

Support for switching movement granularities

It is now possible to traverse through text on a web page by character, word, or paragraph using the usual TalkBack gestures in Jelly Bean. Switch your granularity to one of these modes and swipe left and right to move, spell, or read word by word.

More braille features

In addition to the braille output introduced in Firefox 24, Firefox 25 also brings a cursor indicator, and you can move the cursor via braille routing keys. Also, if you type something into a text field on the web, braille will now update properly to show you what you typed.

Better support for web applications reacting to touch events

Mobile web applications such as Mobile Twitter will now work much better for TalkBack users. Before, it could happen that if you double-tapped nick names or tweets in your timeline, nothing would happen. Now, we correctly pass on touch events, which Mobile Twitter expects, so you can do things such as reply, retweet and other actions pertaining to the current tweet, view the user profile etc.

Better touch targets

Firefox for Android now allows for a better explore by touch experience by improving the discoverability of certain web elements such as plain text.

…and more

There have also been bits and pieces added, changed, and optimised to make reading web content more reliable, especially if there are frames and iframes involved.

I hope you’ll enjoy these new features! Happy browsing!

Yes, that’s right, I grudgingly accept the fact that aria-hidden is here, and most probably here to stay. Those of you who know me and have been involved in discussions with me, like poor Victor Tsaran, whom I pestered more than once to give me tangible evidence that aria-hidden solves problems normal visibility techniques don’t, know that I’ve been always a strong opponent to give web developers that much power over the accessibility tree. Unlike role “presentation”, which marks only one particular element as uninteresting for accessibility, aria-hidden does the same for an element and all its child elements.

Especially considering that Chrome and Safari mercilessly prune the whole tree underneath and including the element marked with aria-hidden=”true”, dangerous things can happen if aria-hidden is used irresponsibly or carelessly. What can happen in such a circumstance is that a child element of that tree is, or becomes, focusable, but there is suddenly no accessible for it.

Firefox, therefore, takes a less offensive approach. We give aria-hidden marked elements an object attribute, but leave the element and its children in tact in the accessibility representation otherwise, so that screen readers can opt-in to ignore the sub tree.

And this is where Firefox OS suddenly comes into play. When Eitan and I started working on this a year ago, we immediately noticed that there were several problems with Gaia, the UI and apps library shipping on Firefox OS devices. It is built completely in HTML, CSS and JavaScript. When i started playing with a device, I noticed that apps were showing me content that was not on the screen, didn’t go away when I closed them, etc.

The reason for this behaviour was the fact that much of the styling in Gaia uses the z axis to “hide” elements. They just get pushed into the background. But putting stuff on a negative z axis does not prune them from the accessibility tree traditionally.

Eitan then started experimenting with changing the visibility to use display: none; or visibility: hidden; instead, depending on the reflow demands. While this solved some problems, it definitely didn’t solve all of them. Most importantly, there were often visual artefacts interfering with animations and other things. And the last thing we want is that accessibility is the cause for visual unpleasantness!

So in the course of the last two months, it became apparent that the least intrusive method of solving this problem is to introduce aria-hidden in strategic places into Gaia to manage what is visible to our screen reader, and what is not. Consequently, our screen reader for Firefox OS was enhanced to support ignoring trees that are marked with aria-hidden.

And here it is, the reason why I grudgingly accept aria-hidden as a useful reality. It not only solves a big chunk of problems with only a few attributes in strategic places. It also makes sure we do not interfere with the visual experience, and it saved us from having to touch each and every CSS in Gaia to manipulate it to fit our needs, and by doing so, cause that visual degrading we want so desperately to avoid. Also, it helps prevent breakage, because Gaia developers can change the relevant CSS without having to be afraid to break accessibility

So while I was searching for external sources to tell me why aria-hidden is actually useful and needed, the reason that convinced me built up inside Mozilla! 🙂

I still think that aria-hidden is a rather dangerous attribute, I count on the educational skills of the accessibility community at large to make sure the situation doesn’t get really bad! And I will do my part to help with that effort!