Blog change: Now using encrypted connections

This is just a quick note to let you all know that this blog has switched over to using encrypted connections. The URLs (web site addresses) are now redirected to their encrypted counterparts, starting with https instead of http. For links to posts you may have bookmarked, it means that they’ll be automatically redirected to their encrypted counterparts, too, so you don’t need to do anything, and permalinks will still work.

For you, this means two main things:

First, you can check in your browser’s address bar that this is indeed my blog you’re on, and not some fraud site which may have copied my content.

Second, when you comment, the data you send to my blog is now encrypted during transport, so your e-mail address, which you may not want everybody to see, is now not readable for everyone sitting by the sidelines of the internet.

This is my contribution to making encrypted communication over the internet the norm rather than the exception. The more people do it, the less likely it is that one becomes a suspect for some security agencies just because one uses encryption.

Please let me know should you run into any problems!

Quickly check your website for common accessibility problems with tenon.io

Tenon.io is a new tool to test web sites against some of the Web Content Accessibility Guidelines criteria. While this does not guarantee the usability of a web site, it gives you an idea of where you may have some problems. Due to its API, it can be integrated into workflows for test automation and other building steps for web projects.

However, sometimes you’ll just quickly want to check your web site and get an overview if something you did has the desired effect.

The Tenon team released a first version of a Chrome extension in December. But because there was no equivalent for Firefox, my ambition was piqued, and I set out to build my first ever Firefox extension.

And guess what? It does even a bit more than the Chrome one! In addition to a tool bar button, it gives Firefox users a context menu item for every page type so keyboard users and those using screen readers have equal access to the functionality. The extension grabs the URL of the currently open tab and submits that to Tenon. It opens a new tab where the Tenon page will display the results.

For the technically interested: I used the Node.js implementation of the Firefox Add-On SDK, called JPM, to build the extension. I was heavily inspired by this blog post published in December about building Firefox extensions the painless way. As I moved along, I wanted to try out io.js, but ran into issues in two modules, so while working on the extension, I contributed bug reports to both JPM and jszip. Did I ever mention that I love working in open source? 😉

So without further due: Here’s the Firefox extension! And if you like it, a positive review is certainly appreciated!

Oh, and if you’re into WordPres development or have often-changing content on your WordPress site, I highly recommend you check out Access Monitor, a WP plugin that integrates with tenon.io, written by Mr. Joe “WordPress Accessibility” Dolson!

Have fun!

Apple are losing their edge also in accessibility quality

This post was originally published in January of 2015, and has last been updated on April 10, 2015, with latest information on the mentioned problems in light of the OS X 10.10.3 and iOS 8.3 releases from April 8, 2015.

Over the past couple of days, a number of well-known members in the Apple community raised their voices in concern about Apple’s general decline in software quality. Marco Arment (former “Mr. Instapaper” and now “Mr. Overcast”) started out by saying that Apple has lost the functional high ground. John Gruber of Daring Fireball slightly disagrees, but says that Apple have created a perception that “Other people’s stuff doesn’t work, but Apple’s stuff doesn’t work, either”. And finally, Dr. Drang looks at the power of leverage in this context. And now, well, here is my take on the subject.

Some long-standing readers of this blog may recall this post I wrote in June of 2009 about my first experience using an iPhone. It was the first time I interacted with a touch screen device that was accessible to me as a blind user.

For several years to come, Apple would lead in terms of including accessibility features into both its mobile and desktop operating systems. Zoom had already been there when VoiceOver was introduced in iOS 3.0, and what followed were features for people with varying disabilities and special needs. Assistive Touch, which allows gestures to be performed differently, mono audio and integration with hearing aids, sub titling, audio description and other media accessibility enhancements, Guided Access for people with attention deficiencies, Siri, and most recently, Braille input directly on the touch screen in various languages and grades. Especially on iOS, VoiceOver and the other accessibility features received updates every year with every major release, and new features were added.

In the beginning, especially in Snow Leopard and Lion, Apple also did the same for OS X. It gradually also added many of the features it had added to iOS to OS X to keep them in sync. But ever since Mountain Lion, VoiceOver did not see much improvement any more. In fact, the lack of newly introduced features could lead one to the perception that Apple thinks that VoiceOver is done, and no new features need to be added.

But, and I haven’t said this for the first time on this blog, the quality of existing features is steadily declining, too. In fact, with the release of both OS X 10.10 “Yosemite” and iOS 8, the quality of many accessibility features has reached a new all-time low. AppleVis has a great summary of current problems in iOS 8. But let me give you two examples.

The first problem was so obvious and easily reproducible that it is hard to imagine Apple’s quality assurance engineers didn’t catch this, and that was on the iPhone in Safari, when going back from one page to the previous one with the Back button. When VoiceOver was running, I hadn’t found a single page where this simple action did not trigger a freeze in Safari and VoiceOver. This was in early betas of iOS 8, and it was only fixed in the 8.3 release released in April of 2015, roughly 10 months after the first iOS 8 beta was seeded to developers on the day of WWDC 2014.

The second example concerned using Safari (again) with VoiceOver, but this time on the iPad. Using Safari itself, or any application that uses one of the two WebView components, I was reliably able to trigger a full restart of the iPad at least twice a day, most days even more often. That caused all apps to quit, sometimes without being able to save their stuff, it interrupted work, and it left the iPad in a semi-unstable state that it was better to fully shut it down and restart it fresh. Update: This, too, was finally fixed in iOS 8.3. But it took quite a number of logs that I sent to Apple engineers before the problem could be fixed. But after I wrote the initial version of this post, in a concerted effort, this could finally be nailed down.

“Wait”, you might say, “this sounds like a problem from iOS 7 days, and wasn’t it fixed?” Yes, I would reply, it was, but it returned in full force in iOS 8. But mostly on the iPad. I think I’ve only seen one or two restarts on my iPhone since iOS 8 came out.

The first of these two examples is such low-hanging fruit that I, if I was working at Apple, would be deeply ashamed that this was around for so long. The second one was harder, but not so hard that an engineer sitting down for a day and using the device with VoiceOver enabled wouldn’t run into it.

But accessibility problems are not limited to VoiceOver alone. Web Axe posted a great summary about problems in other areas such as the default settings for paralax effects, button shapes and more. Go check it out for more information on those topics!

And now back to Yosemite. I again concentrate on Safari + VoiceOver, since this is where I spend a lot of my time. Support had regressed so badly in the initial 10.10 release and the first 10.10.1 update especially on dynamic pages that it was barely possible to use Facebook on Yosemite with VoiceOver. VoiceOver skipped over whole stories, lost focus, and did all sorts of other funky stuff. It took until the update to 10.10.2 on January 27, 2015, 3 months after the initial release, to at least largely address these problems. Moreover, editing in any form field on the web was so slow and double-spoke that it was not really possible to do productive work there. And if you had a braille display connected, you could expect it to drop out every few seconds when moving the cursor. The sounds VoiceOver made were the equivalent of plugging and unplugging a USB braille display every 3 to 4 seconds. These also were corrected in the 10.10.2 release. In fact this update is written in the MarsEdit blog authoring software, and using that hadn’t been possible with VoiceOver until 10.10.2.

All of these problems have been reported to Apple, some by multiple users. They were tweeted about publicly, and now I am reiterating over them again to show my support for Marco, John, and others who assert rightly that Apple has a real quality problem on their hands, which higher management seems to be quite thick-skinned about. Blinded by their own brilliant marketing or something? 😉

Apple does have a fantastic accessibility story. No other operating system I know has so many features for such a big variety of people built-in (speaking mostly for iOS now). But they’re on the verge of badly trumping that trust many people with disabilities put in them by delivering such poor quality updates that make it virtually impossible to take advantage of these features in full force. Especially when such basic functionality as I describe in Safari, and AppleVis summarize on their blog, are getting in the way of use every minute of every day now. And Apple really need to be careful that others may catch up sooner rather than later. On the web, the most robust accessibility is already being delivered by a different desktop browser/screen reader combination on a different operating system. As for mobile: Android is the lesser of the competition, even in its latest update, in my opinion. But Microsoft’s foundation is really solid in Windows Phone 8.1. They just need to execute on it much better, and they could really kick ass and become a viable alternative to Apple on mobile.

Fortunately, with the release of iOS 8.3, Apple finally came to their senses and included a big number of accessibility fixes and polish, which AppleVis summarizes in this blog post. Here’s to hoping that the rumors come true that Apple will be focusing a lot more on stability and polish in the iOS 9 update, expected to be in beta at around their developer conference later this year. I think the fact that iOS now has a public beta program, too, is a good sign for that, and it gives more people the opportunity to test and report problems early.

So here is my appeal to Tim Cook, CEO of Apple: Put action behind these words again! Go to these extraordinary lengths you speak of by not just cranking out new features that are half-baked, but make sure your engineers work on the over-all quality in a way that does not make your most faithful users feel like they’re being let down by your company! Because that is, exactly, how it feels. This trend started more strongly in iOS 7, and even worsened in iOS 8. And it has been with OS X even longer, starting in Mountain Lion and worsened ever since. Please, show us, our friends and family who started using your products because of our recommendations, and those of us who took a leap of faith early on and put our trust, our productivity, our daily lives in your products, that these are not just empty words and that that award you received actually means something beyond the minutes you gave that speech!

Sincerely,

a caring, but deeply concerned, user