Alex's blog

Sometimes standardization might have amusing consequences.

Some preliminary. Say the web author need to place an image for pure design purposes, it could be a background image for example, and of course the author doesn't want it to be visible for screen reader users. So the author can do:

<img src="blabla.jpg" alt=""/>

This technique is well known and was standardized by Techniques for UAAG published at 2002:

In some authoring scenarios, empty content (e.g., alt="" in HTML) may make an appropriate text equivalent, such as when non-text content has no other function than pure decoration, or when an image is part of a "mosaic" of several images and does not make sense out of the mosaic.

Neither browser nor assistive technology is supposed to repair the text equivalent for empty alt image or in other words it should be no image from the user perspective. This technique was supported by Firefox and by number of screen readers over the years. On implementation level the trick is accessible name of the image element is an empty string what is interpreted by screen reader the image should be ignored.

Then after years as accessibility standardization process goes on we've got a quite good initiative which is HTML accessibility mapping. Among other things, it has HTML to ARIA mapping. This is nice but brings ARIA on the level of universal accessibility language while it barely fits all nuances of HTML markup. When it comes to HTML img alt="" case then the closest thing popping up in ARIA is role="presentation". Semantically it looks good, however it doesn't match the accessibility API mapping we used to have for years. The change can be made both on browser and screen reader sides but it doesn't have any practical benefit.

By the way the topic seems constantly bother accessibility minds through years. Not taking into account the fresh bug, we had same bug 4 years ago.

Sometimes the web authors provide a different content for screen readers than they do that for sighted users. That could be an additional content like "skip to content" navigational links or set of landmarks to create a more reliable document structure. In some cases the web author might want to remove a content, for instance, duping links, or make extra tricks to keep the content accessible if, for example, the author gets out of the standard HTML. In ideal case of course the content is supposed to be quite the same but because of design issues and HTML imperfection it doesn't really happen. The web repletes with examples of special content for the assistive technology.

The need of alternative content

Usually authors don't need to put significant changes into a web page to make it accessible. Keeping in mind usability aspects and following best practices is often enough for good results. In other words this is the kind of changes (except some ARIA) that is supposed to be useful for everybody. Sure it doesn't count the web pages having large pieces of ARIA but that's rather an area of large web apps and custom widgets.

That's how it is but nowadays tendency is getting changed and certain web apps want to provide whole portions of alternative content for the assistive technology.

A few examples are good for demo proposes.

Couple examples
Shared video example. If blind and sighted users want to share the device to watch the movie then it might be good idea to have audio descriptions shown (announced) for the blind user only.

Camera apps. It may be another use case of separate content for blind and sighted users. A camera app shows what's on the camera and may have graphic-only interface like green rectangle showing the thing that is currently in focus. A screen reader user may benefit if the face detection software beeped when face gets in focus since it gives a good chance of nice picture.

Another example can be QR code reader software which helps to find QR code label on the product. In general all camera apps may benefit from giving special instructions for assistive technology users.

Integration vs personalization
So alternative content for assistive technology can be a part of the web app design. A next question is how the alternative content can be added into the web page. Would it be one integral app explicitly and implicitly containing special content or will it be personalized version of the app designed for the assistive technology.

Both approaches have own benefits and disadvantages. So that personalization approach wins in performance since potentially the app doesn't need to combine two different versions into one (and actually it is a big concern of web apps vendors from what I hear). Benefit of integration is people get all-in-one solution what mean users share the app and usually have same experience.

Privacy concerns
A big issue of personalization the people talks about is privacy. If you want to have a personalized version of the web site then you have to tell the web site you use the assistive technology.

The idea of sharing personal information is not comfortable in general for many people and it's quite understandable. But you need to keep in mind that those who wants to know whether the user uses the assistive technology quite likely have a way to detect this. These are solutions like screen reader sniffing flash plugin or JS script based on the difference in content navigation. For example, it didn't take much time for me to write a simple script (can be found attached to Mozilla bug) to detect the NVDA screen reader. These solutions are not perfect and may give false positives but I'm pretty sure they can be improved if somebody wanted.

On the another hand if the user says he wants a specialized version for assistive technology then it doesn't necessary mean the user has the assistive technology running and of course it doesn't necessary mean the user have to share what kind of assistive technology he uses.

So of course there's a privacy concern but it's not bigger than, say, privacy concern of Geolocation API. The difference in sharing and not sharing is rather seeming. After all the user decides.

Tech party
Not sure which approach will get dominant, perhaps that will be some reasonable mix of them. Anyway it would be a good idea to provide web authors the different techniques to implement either approach.

  JS API
Just a method to detect the presence of assistive technology such as a screen reader allow the web app to load specialized scripts and build personalized version of the app. The idea in implementation can be quite similar to Geolocation API. If the web app wants to know whether an assistive technology is running then the user gets asked if he's ok to share this info. If the user agrees then personalized app is loaded.

aria-hidden
It can be used to hide certain parts of the web page from the assistive technology and (quite a recent change) it can be used to create web page portions for assistive technology only (not visible/operable/etc for sighted users).

Actually at this point ARIA spec doesn't allow aria-hidden to create web content for AT. However w3c pushed this option into the law by resolving HTML5 bug. I admit that next ARIA spec should get in sync with the change. It's worth to notice however that WHATWG spec hasn't been changed yet and probably it won't be.

Also ARIA recommends very limited usage of aria-hidden:

Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.

I suppose it may be considered as temporary advice and will be neutralized as soon as the web gets more apps having special versions for the assistive technology.

So here's a demo of the approach

<body>
  <div aria-hidden="true">An ordinal version</div>
  <div hidden aria-hidden="false">An assistive technology version</div>
</body>

The minus of the aria-hidden="true" is the user navigable content is hidden from the assistive technology. You may want to read the post why I didn't fell in love with aria-hidden="true" as it's stated. My opinion haven't really changed over years.

The minus of aria-hidden="false" is AT visible only content is not keyboard navigable until AT has special support of it, it's not focusable and has neither dimensions nor position what is a certain restriction for AT. Also it's good to note, screen readers like Orca would ignore aria-hidden="false" content in general because it requires a virtual buffer feature for content navigation but Orca doesn't have it in question.

So aria-hidden has bunch of disadvantages but I admit it has one good benefit which is its simplicity for the web author.

CSS media   CSS media features are designed to provide styling depending on features the device has. So if screen reader is detected then the web app can show or hide portions of the page when it makes sense for screen reader users, for example,

@media (screenreader) {

  .sr {

    display: none;

  }

}

<div class="sr">hidden from AT</div>

As you see it's very easy to change the web page and personalize it for the assistive technology user. This technique doesn't have disadvantages of aria-hidden because all content is rendered on the screen. So that the content has position and size, it's focusable and navigable by standard ways.

Nevertheless CSS media is also disputable approach (check out Mozilla bug for details). Note, afaik it's not supported by web browsers yet.

Two screens option
Same screen approach looks quite appealing but it doesn't answer to all designing needs the web authors want. For example, in the case of shared screen to watch the movie it might be a nice option if audio descriptions were shown only for those who needs them.

This idea leads to the option to render CSS media styles virtually. Technically speaking that means the presence of two screens, i.e. one version is rendered on the display (that's a movie), the second version is rendered in memory, for assistive technology only (subtitles). Nowadays a similar thing is implemented for HTML 5 canvas shadow content: it's not visible on the display but the assistive technology literally sees it, i.e. it have an access to layout, position and dimensions, and it can navigate it.

It's not clear however how to share input devices like mouse and keyboard, but probably it could be nicely resolved this or that way. This approach is quite close to aria-hidden technique since it allows same design techniques but it doesn't have disadvantages of it because the content is still rendered.

The web is going to change the way it handles the assistive technology. Quite soon I think.

Browsers traditionally overlook MathML accessibility besides MathML implementation itself by some of them. Because of that there is a bunch of 3d parties software to display MathML and expose math content to assistive technology. They do a good job but what relates to screen readers support it's far from being perfect.

So MathPlayer works with IE only. MathJax, a cross browser math renderer, claims they do accessibility by means of MathPlayer. Last time I checked MathPlayer did a trick by adding accessible properties like accessible name to MathML nodes in accessible tree. There's a bunch of problems with this approach like the user can't control the speech output. However I must admit it makes screen readers to read math.

Main problem here there's no right API and they have to use existing APIs which is Procrustean bed for math. The browser and assistive technology have to invent something that describes math well. Until that there's no right tool to succeed. I should notice that above-mentioned primarily applies to Windows and Linux worlds. Much to my surprise WebKit has got a math accessibility API on OS X last year. I didn't hear VoiceOver picked it up yet but as soon as it does the MathML content should become accessible on Mac.

In Firefox we have a meta bug to track MathML accessibility work. As the first step on this way Firefox 27 started to create generic accessible objects for MathML elements. It's not so valuable by itself because a generic accessible don't expose any math semantic but it allows the assistive technology to navigate the math and watch for tree mutations. Next we could follow WebKit effort by extending ATK and IAccessible2 APIs to make math accessible on Windows and Linux but I have been told libraries that screen readers rely on to process MathML speak also MathML language. It might be unwise to split MathML into atoms of high level API to make the assistive technology to reconstruct MathML on its side.

Gecko exposes ISimpleDOMNode interface providing a direct access to DOM for assistive technology. I never was a devotee of ISimpleDOM because I believe that high-level APIs like IAccessible2 are more efficient. But in case of MathML it's apparently not true. Having said that I think it'd be good to have something more sophisticated than plain DOM to implement, for example, an extended math navigation. Otherwise I think AT have to learn some MathML.

So we stopped at this point for now. Assistive technology can navigate the MathML tree, get MathML markup and feed it to utility libraries processing the math. It looks good for a start, at least after years of keeping silence. Ostap Bender would say the ice has broken, ladies and gentlemen of the jury!

If you have ideas, thoughts to share you're welcome to comment our meta bug.

XTF and XML events are removed from Firefox (see this and this) and that's supposed to be a last day of Mozilla XForms project which was built on these technologies. Mozilla XForms was nearly dead for a while and it was kept alive by Philipp Wagner. Now it's over. So we decided to remove XForms accessibility support from Firefox.

XForms was a project that my Mozilla story has started from. I worked for a local company in the city I live. They created Mozilla based applications and in particular they were interested in Mozilla XForms. XForms was a really promising technology since it supported natively a model view pattern and provided a nice mechanism to map data to UI. However Mozilla based applications were written in XUL but Mozilla XForms didn't have XUL UI those days. So they decided to put me working on Mozilla XForms project to fix that. That's how I've met XForms guys: Allan Beaufour, Aaron Reed and Olli Pettay.

Year later I was moved to another project. I had a chat to Allan and I said that I'm really upset that I can't spend much time on the project anymore. After several days Allan asked: Do you still want to continue your work? I said: Of course. He said: there's an idea to make XForms accessible, I will introduce you to one guy. That's how I've met Aaron Leventhal and that's how my Mozilla accessibility story has started.

Note (just in case): XTF and XML Events were removed in Firefox 19. Firefox 17 and Firefox 18 aren't affected. That means next ESR release is not affected too.

I'm not a real part of ARIA spec development but I work with assistive technology vendors and ARIA widgets authors on ARIA support in Firefox, I'm the one who implements ARIA in Firefox. I'm focused on practical aspects of ARIA usage and often I deal with problems not addressed by ARIA spec.

Here how it usually works. We and AT developers discuss a problem and then after agreement we implement just a reasonable solution that works for AT, users and us. We don't always go for a feedback from ARIA group and actually I think there's a number of reasons why. Personally I don't go probably because

• I think somebody else could do that since it was a group decision after all.
• I don't always get feedback from ARIA group.
• ARIA group is perceived as a closed group (I always run into restricted areas the other participants are referred to).
• ARIA group structure feels complicated (there are two ARIA specs managed differently and when you have a single ARIA issue then sometimes you should go though different authorities to get a feedback).

I think it's because I didn't have a really good story of collaboration with ARIA group.

On the another hand I don't follow the ARIA spec progress. I didn't see changelogs between spec versions. I wasn't really asked for feedback as ARIA implementator in Firefox. Because all of this many changes in the spec were introduced silently for me. I don't want to blame anyone (including myself) I just want to say that ARIA spec development was in parallel universe for me.

Yes, it couldn't be forever, one day Firefox implementation should meet the spec on the crossing and we should get a bump. This day have came. ARIA spec came into candidate recommendation and we were said Firefox don't pass tests. While I was running through failing tests one by one then I realized I have concerns for half of them. It wasn't a really big surprise but I disagreed what ARIA spec states in a number of cases. Here are few examples when I had concerns.

1) ARIA abstract roles must be not exposed via standard role mechanism (see the ARIA spec):

User agents MUST NOT map roles defined in the WAI-ARIA specification as "abstract" via the standard role mechanism of the accessibility API.

It seems very reasonable since there's *no* any single reason why the AT would need it. But the statement might be colored differently if you read it as implementator. If the browser exposes only known and "good" ARIA roles then the browser is in good shape and it goes with the spec. The browser can do different approach and expose all ARIA roles (not depending whether they are known or unknown) and let the AT to decide what to do with them. You can argue whether this is a good idea or not but it can be used in the wild, for example, by scripted JAWS and certain web apps (in this case the browser is just a mediator between web app and screen reader). Also the spec doesn't deny that.

However if the browser follows this approach then we run into a problem because the browser must known about abstract roles to ignore them. Abstract roles are pure theoretical matter used to organize stuff in the spec, it's *not supposed* to be used on the web and it *won't* be used on the web but the browser *must* know about them if the browser relies on "expose any role" approach. In reality it slows down the browser for nobody's win. Ok, it's a browser problem. ARIA problem I think is the ARIA spec tries to standardize things that *aren't* supposed to be used on the web what is meaningless in general.

2) aria-checked="mixed" on radios should be mapped to "false" value (see the ARIA spec):

The mixed value is not supported on radio or menuitemradio or any element that inherits from these in the taxonomy, and user agents MUST treat a mixed value as equivalent to false for those roles.

I agree mixed value on radios don't make any sense since radios don't support tristate. But the "false" value is not a fallback value on radios. That means the browser *must* introduce a special check for the case that doesn't have *practical* usage on the web.

The problem is the candidate recommendation means nobody wants to change the spec at this point especially if it's implemented by some browsers already. It doesn't really make sense to address any issue listed above in the next spec since they don't make a difference on the web. It wouldn't be so bad to just follow the spec if we didn't have other discrepancies especially those that *make* a difference for the user.

The reality is either Firefox picks up that burden wordlessly or it gets an yoke of the browser incompatibility with the spec. No good options, huh?

Recently I booked the flight for me and my family. After some search I stopped at Rossiya airlines (Saint-Petersburg's airlines). It was new airlines for me but they offered the best option.

So I started booking and somewhere in the middle I decided to use another bank card. I pressed cancel button (instead the pay button) and it says the payment failed. No option to retry.

I tried to dial the call-center of Rossiya airlines, several times, but no any luck to ring till the bell is answered. So I wrote them email and in few minutes I got an answer:

Unfortunately you can't pay by bank card online if you rejected to do that once. But you can pay in our office, choose another payment type or book another flight.

Sure I tried to book the flight again but the price surprised me. It wasn't the best option anymore. So I decided to pay existing one and since another payment type usually assumes a noticeable fee then I said:

Ok. What is address of your office in my city.

They said:

Unfortunately we don't have offices in your city. You can try to pay by VTB-24 ATM or in VTB-24 bank office.

I asked about the fee. They said no fee. Ok, nice.

I located VTB-24 ATM near of my house and tried to pay. When I typed the payment info then the ATM said that it can't process this request. I thought maybe VTB-24 ATM can vary, thus I checked Rossiya airlines web site which ATM can be used to make this payment. Next day I tried another VTB-24 ATM. This time when I specified all payment info it said "the feature is not implemented". The farther into the forest the thicker the trees I thought.

So I came to the office of VTB-24 bank to make a payment. They said I can't pay by my bank card. Of course if that was a bank card of their bank then I could do that but otherwise they can't help me and they need a cash. So I moved to ATM of my bank and got that cache, got back to that office and oh happiness I did that.

Say me what a heck I pressed that cancel button.

Finally they saved us from standing in long lines and millions of forms fillings when you need to get social services from government. Now you can fill up millions of forms online. Yep, that's great. My travel passport gets expired soon so I decided to obtain a new one online.

I went to gosuslugi.ru where I were asked to sign up. I entered my ID number (well, it's not ID in terms of USA but close at some precision) and they said they will send me activation number by post mail. "Ok" - I thought and after couple weeks I've got a letter with activation number.

Then I activated my account. It was tabbed UI.  First tab "enter ID and activation numbers". Second tab "pick up a password". Third tab: "you see a message that account is activated". So due to some reason they skipped a second tab. They said my account was activated and now I can use it. "Ok" - I thought and tried to use it with empty password. That didn't work. Fortunately, they allowed me to pick up new passport after usual procedure with confirmation by email. "Ok, great" - I thought - "let's move further".

I was ready to fill up the form to request a new travel passport. That was a big form, yep, really big form. I should point who I am, my birthplace, my existing passports, all my jobs and etc, shortly speaking all my biography.

That was a bit unusual UI. I need to choose where I want to pick up the passport when it's ready. You can imagine how Russia is big and how many places to pick up the passport it could have. These options weren't sorted by cities. I listed them one by one looking for a proper one. My wife suggested to start from the end (she had experience to get the travel passport online, well, she didn't get yet) and - oh happiness - my option was in first dozen of options from the end.

I'm not sure why but my browser shows enabled and disabled controls on this web page the same way (I assume that's page styling). The required control elements are marked by red asterisk, this applied to enabled and disabled controls both. Usually when you choose a value in combobox then some controls gets enabled or disabled. So what I did? I clicked any form control to make sure I don't miss anything important.

What UI control would I use if I need to ask a question with answers "yes" or "no". First of all I think of checkboxes. These guys decided to use comboboxes with three options: yes, no and empty (default). I guess they did this because they wanted to make sure the user chooses something and don't skip the question by mistake. Well, this point makes sense but obviously it's not user friendly.

Every region in Russia has a number. So, Irkutsk where I'm located is 38. How many people knows this number and how many people think about the number where they are asked about their region? I'm pretty sure if you have a car then you know the number (because the car number contains a region number). But I'm not sure your answer would be 38 if you were asked about the region you are located. What do I say this for? They have a combobox with options like "38 - Irkutsk region". What do I do when I want to choose my region from list of options? I focus it and start typing "Irk" and etc and expect that I choose the Irkutsk region. Yep, that doesn't happen because they used numbers as prefixes. I run through all options and find a needed one and only then I understand what all these number mean and why I wasn't able to find Irkutsk by typing.

Ok, let's move next. I was asked to point all jobs I had (period, company name, job title, address). They provided a button "add item", by clicking it the new row appears and you can describe next job. They provide neither button "remove item" nor UI to change items order. But I was lucky and typed everything correct.

Finally I reached the form end. I didn't attached my picture yet but clicked on checkbox "Sign the form", I guess that should be similar to the statement "all information I pointed above is true".  But to all appearances it wasn't right guess because I've got an alert message saying that I can sign the form in Internet Explorer browser 6.0 or higher only. I'm Firefox user. I'm Mac user. I don't have IE. I hung for a couple minutes thinking in pretty warm way of site developers. And then I saw the last-hope button "save the form on your computer", I clicked it. The form was cleared and I didn't noticed anything else. Firefox downloads dialog doesn't have anything downloaded. Downloads folder is empty.

I think it's too much for me to repeat these steps today if I find IE 6.0 or higher. I'll fill up the form next time.