"Some important buttons on the main screen remain unlabeled. Fortunately it's not too hard to figure out what they do with some trials."

What sort of user experience is this? An all too common one, if you are using a screen reader. The title is a quote from a review of the iOS version of the Duolingo app on the AppleVis site, where blind and low-vision users help each other use Apple products and apps running on those platforms. Here is the review in full:

In spite of issues making recent versions totally unusable, this version is once again usable. However, even though it is [usable], there are definitely some annoying problems to watch out for. The first is that some important buttons on the main screen remain unlabeled. Fortunately it's not too hard to figure out what they do with some trials. The second is that there is no way to tell what color your tree is. This means that you can't determine if you need to strengthen weak skills or not. You also can't easily figure out which skills are complete. The third issue is that it's not always possible to reread what you've typed, in questions where you're expected to enter your answer via the keyboard. In spite of these major problems, I still use the app regularly, because the app is really good at what it does.

 Review by Aron C on the AppleVis web site. First added on August 13, 2013; updated on October 4, 2017. Emphasis mine.

The review has over 70 comments, many of which involve posters helping each other figure out how what to do when they have gotten stuck. For example, at one point a suggested workaround for reaching the settings included temporarily turning off the screen reader to tap a button.

The comment thread ought to be required reading for anybody involved in the production of user interfaces, not least to dispel any doubts that people with vision impairments use smartphones and have reasonable expectations on usability just like everyone else.

Things are about to change, at least for one class of applications. As of September 23, 2018 the EU directive on the accessibility of the websites and mobile applications of public sector bodies is in force. It became Swedish law on January 1 2019: Lagen om tillgänglighet till digital offentlig service (in Swedish, published by the Agency for Digital Government). New public sector web sites need to be accessible by September 23, 2019; existing ones by September 23, 2020; and mobile apps by June 23, 2021.

The Swedish publication states that "the requirements to which web sites and mobile applications will need to conform are yet to be decided" (my translation) as they are still in progress. It adds that they will likely be based on a European standard based on WCAG 2.1 AA, a document that lists requirements both for web and mobile apps. I have to admit to being surprised by the fact that there is a compliance date in the relatively near future without any official requirements (all too familiar in the software industry, I know!). But assistive technology is not new, nor is legislation in the area, with  the US congress having enacted Section 508 of the Rehabilitation Act of 1973 in 1998. There should be plenty of experience to draw on.

Lack of specifics notwithstanding, it can safely be assumed that the standards will require accessibility for users without vision, users with limited vision, and users with limited color perception. For these user communities, the implementation techniques involved in supporting them are well understood, whether it be for mobile or web apps, so there is no reason to wait - good usability (not to mention good governance) means access for everybody.

While the mobile app compliance date is a couple of years out, adopting an approach of wait and see  is not a good idea. Apart from the common decency argument, accessibility is a lot like internationalization - it can be added afterwards, but things will go a lot more smoothly if everybody involved understands from the get-go that dynamically sized fonts, like message translations, mean that the size of elements is not fixed. (Also, it is not unusual that actions which improve screen reader experience constitute usability improvements at large.)

I am going to evaluate some Swedish public sector apps, both mobile and web, to see how they fare with respect to screen readers and accessible font sizes, and will post the results here. First out will be the iOS versions of "Mina Sidor" published by by Försäkringskassan (the Social Security Administration) and BankID, an app that allows users to authenticate themselves electronically that is one of the accepted means of authenticating with government agency sites. Until then!

PS. If you want to try out a screen reader on your smartphone, the iMore accessibility guide is a good resource for getting started on iOS devices. Google's Talkback guide explains how to use the Android built-in screen reader.

Why do I see the wrong business hours in Facebook and Google business listings?

I have lived in Sweden for a handful of years now, and am slowly coming to grips with the country taking a collective break during weeks number 28-31 (yes, figuring out when that is, is a test).

This summer I have (among other things) failed to bring pastries to a party and missed out on a visit to the public library because I thought that Facebook and Google were showing me the current business hours.

I should probably have learned to call ahead by now. However, as a "vän av ordning" (friend of orderliness), and also as somebody who has had the (mis)fortune to work on calendaring tools for a significant portion of my career, I wonder how hard it can be to do it right.

If I were going to develop this, it seems like the easiest (?) approach would be to get the business hours from a calendar. Google can even direct users to create one with their own calendar UI. Now (I'm thinking), the business owner can sit down in January, wrapped in a blanket and with a big cup of tea, and create recurring events for their regular opening hours and exceptions for public holidays, weeks 28-31, and the annual company shrimp-eating jaunt.

My "Enter business hours" UI will consist of a textfield where you paste the URL to the calendar. Then I do some magic CalDAVing and display the correct business hours (or non-hours) for the week. Nobody will be stand outside a closed door with a long face longing for tartes a l'abricot. I am a hero!

But given that I haven't had great luck with looking up business hours on Facebook or Google, I suspect that this is not how their UIs work.

Looking at Facebook business pages, the UI for business hours contains seven rows corresponding to the days of the week, where you can enter start and end of business hours.

In other words, the stressed-out-of-their-skull business owner, who is desperately trying to get everything wrapped up before loading their car to the gills with kids and paraphernalia to go to the summer house has to remember edit the Facebook page on the last day (and the Sunday before they open again). So it's understandable that Facebook business hours might not reflect holiday closures.

Another interesting question is, what do Spanish businesses do? They usually close in the middle of the day, but this UI can't capture that..

With Google, the basic UI is similar to Facebook's, but Google does go further: it is possible to set non-contiguous work hours, and to change the hours on special days. Importantly, you can specify the exceptional days in advance, so entering the data is not time-sensitive. You can even upload the data from a spreadsheet, but interestingly, you can't specify a calendar.

I think we can agree that Facebook makes it too hard for users to do the right thing. Specifying known departures from normal business hours is something that you should be able to do well in advance.

But it also seems like just offering the ability to enter non-normal business hours in advance isn't sufficient, that is, it doesn't make it easy enough to ensure that business owners actually do it. There is something about the Google UI that doesn't sufficiently prod business hours to think of the non-normal weeks.

Which brings me back to the calendar based solution I mused about earlier. Perhaps thinking of business hours as events on a calendar could be the prod that makes the user remember to deal with exceptional dates?

There are other advantages too - if the data for the business hours was a calendar URL, then the business owner would potentially be able to use a single calendar URL for all apps that display their business hours - what a time saver! And if you are suddenly struck by vomiting disease, you wouldn't have to log in to Facebook, Google, et al and change them. You just grab your mobile phone and delete the opening hours on that day and it is hopefully reflected in the UI in the near future. (No connection between vomiting disease and any businesses I may have tried to visit during the summer, I should point out).

But maybe the world isn't ready for exceptions to recurring events?

What do you think? Let me know!