Exploring the Google Cloud Functions Environment

I’ve been having a great deal of fun recently playing with Google’s Firebase cloud service. In particular, the Google Cloud Functions are pretty amazing. Yes, I’m aware of AWS Lambda, and I’ve written code for it while working for Instructure, (which I assume is still being used in production today). However, Amazon’s Lambda is a huge pain to get working. Well actually, it’s more accurate to say that API gateway is the painful part. Firebase Functions, on the other hand, are a breeze.
Anyway, the whole idea with serverless functions is that you don’t have to worry about the machine. Just push your code, pick your CPU and memory requirements, and you’re good to go. However, in practice, it can often be handy to know a little more about the environment. For example, I wanted to know if the bzip2 command was available. Of course, that got me wondering what else might be available, or missing. So, I wrote a little scfuncon to give me this information.
Continue reading

Hiding or Disabling

I recently reviewed a web-based file manager for accessibility. It was laid out as a table, with information about each folder or file inside its own row. Each item could be opened by clicking it’s name, or selected via a checkbox, for further manipulation.

Above the table was a set of action buttons such as “Move”, “Rename”, “Delete”, etc. These buttons would appear when one or more items in the table were checked, and disappear when no items were checked.

This worked well for folks who could see, but posed a problem for screen reader users. How would a blind user know that the action buttons had appeared? We could have added an ARIA alert, but that probably would have been more confusing than helpful, and wouldn’t have help screen reader users know where to find the action buttons.

The solution we ultimately adopted was to not hide the action buttons at all–at least not for screen reader users. Instead, we made the buttons hidden for everyone except screen reader users, and marked them as disabled. That way, since they came before the table, screen reader users would see them, and they would hopefully deduce that if they wanted to perform any of those actions, they could do so after selecting the files or folders.

The takeaway from all this, in my view, is that when causing new controls to appear on screen, that are far from where the screen reader user is currently “looking”, can require some careful consideration to ensure that the user knows that they have appeared, and where to find them. I am not aware of any clear solution to this problem, and I believe that it is best avoided if at all possible.

Accessibility Bookmarklet for StackOverflow.com and Friends

Update: This issue has now been fixed, making this hack unnecessary.

Recently, the developers behind StackOverflow.com changed their site in such a way as to make voting and flagging inaccessible. So, I created a bookmarklet to correct the issue, and these functions now seem to work fine for me with a screen reader. Note that this will likely not work for older screen readers that don’t speak ARIA.

Of course the best solution would be for the StackOverflow devs to make these changes to their site directly, but until that happens, we will have to make do.

It’s amazing what just a little bit of ARIA can do.

javascript:(function(){$(‘a, .vote-up-off, .vote-down-off, .star-off’).attr({role:’link’,tabindex:’0′});})()

Simply right click the above, and save it as a bookmark. Then, when you visit the StackOverflow site, or any of their sister sites, click the bookmark, and the page will magically become accessible.

The biggest drawback to this is that you have to run the bookmarklet each time you visit a different page on the site. So, if you visit the site frequently, I suggest you install the script into Greasemonkey, and set it to run on all pages of the site.

Feedback/improvements are appreciated.

Use ARIA to Indicate When Form Fields Are Required

The next time you create an HTML form with required fields, consider adding the aria-required=”true” attribute to the required control.

<input type=... aria-required="true" .../>

From the ARIA draft:

Indicates that user input is required on the element before a form may be submitted.

For example, if a user needs to fill in an address field, the author will need to set the field’s aria-required attribute to true.

Note: The fact that the element is required is often presented visually (such as a sign or symbol after the widget).
Using the aria-required attribute allows the author to explicitly convey to assistive technologies that an element is required.

Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.

This property is supported in just about all screen reader/ browser combinations that support ARIA. However, for backward compatibility, you should still include some sort of notice in the controls label. An asterisk seems to be the most common, and most users know what it means.

When a modern screen reader encounters a control with the aria-required property set to true, it will simply say “required” in addition to announcing the control type. For example, jaws will say “required edit” when it encounters a required text entry field.

As with every accessibility feature, be careful not to over use this. A good rule of thumb is if you visually indicate that a field is required, indicate the same with ARIA. Likewise, if you don’t visually indicate that a field is required, then don’t do so with ARIA either.

With HTML 5, Much Accessibility Will Come Free

Based on current estimates, HTML 5 will not become an official standard until 2022 (not a typo). However, browsers are expected to support most of it long before then. This is quite fortunate from an accessibility standpoint, as HTML 5 fixes or erodes a lot of the major accessibility barriers that disabled web users currently face. But what’s even better is that web authors won’t have to do anything extra to enable most of this added accessibility. It will come standard with the proper use of HTML 5.

Let me be clear, there will still be a need for ARIA, and most of the web accessibility best practices won’t be going anywhere anytime soon, but it seems likely that web authors will have fewer things to worry about when it comes to accessibility, and web sites that weren’t designed with accessibility in mind will be more likely to just work.

Here are some of the immediately obvious benefits to accessibility that HTML 5 will bring.

The ContentEditable Attribute

This attribute allows one to make the contents of a particular tag editable, also known as “edit-in-place”. This attribute is already supported in many browsers, and it seems to work well with Jaws. When taken together with the fact that I can’t recall ever seeing an edit-in-place implementation using JavaScript that was accessible, I recommend using the contenteditable attribute as soon as it becomes practical to do so.

The Header, Footer, Nav, Section, Article, and Aside Tags

It recently became possible for web authors, via the use of a span tag and ARIA landmark roles, to tell disabled users “this section of the document is the header,” or “this section is for navigation.” Before that, we had to use clunky “skip to XXX” links. Now, if you wrap the various parts of your page in header, article, and similar tags, you should get the same functionality that the ARIA landmark roles give, but for free, without any extra effort on the part of the web author beyond writing semantically correct HTML (I.E. not wrapping the footer of a page in a header tag). And, as has been seen time and time again, free accessibility tends to be widely implemented accessibility.

SVG Support

While SVG is currently supported by many browsers, HTML 5 broadens that support. The reason SVG support is good for accessibility is that SVG images are vector images (meaning that they are mathematically defined), and so they can theoretically scale infinitely without a loss of quality. This is important for those who use magnification, as these folks often view web pages enlarged up to 16 times or more, which can obviously make typical images for the web look terrible.

Audio and Video Elements

With apologies to the fine folks at Adobe who are doing a lot of great work on accessibility, the sooner flash audio and video players are gone from the web, the better it will be for accessibility. Yes, such players can be made reasonably accessible, but the fact is that most aren’t. I’m convinced, based on past experience, that if we can move the player logic out of a browser plug-in and into the browser itself, we adaptive tech users will have a much better shot at being able to access it.

Drag and Drop

This is also something which I can’t recall ever seeing implemented accessibly. However, it is likely that if this logic can be handled directly by the browser, and not by a JavaScript hack, then screen reader manufacturers will have a pretty good chance of being able to make it accessible via the browser’s API.

Advanced Form Features

HTML 5 will support some new types of form controls (like date/time pickers, sliders, and so on) and will also add new functionality to the traditional form controls (such as autocomplete and client-side validation). These have traditionally been implemented in JavaScript, with varying levels of accessibility (usually poorer than not). However, here again, we have a situation where moving this logic into the browser will make things much more consistent from site to site, and thereby enable screen readers to provide access.


In case you haven’t noticed, the theme here is consistency. The problem with making (for example) autocompletion work with JavaScript is that everyone does it differently. The browser doesn’t know, hence the adaptive technology doesn’t know, that your form field uses autocompletion. At best, it simply knows that we have a text entry field with some JavaScript attached to onchange events. So, since the screen reader doesn’t know that the field offers autocompletion functionality, it doesn’t know that it should present anything differently to the user.

A historical parallel for all this is layout tables. Several years ago, everyone was using tables for layout, because the technology of the time didn’t offer any good alternative. But then CSS came along and layout tables became (for the most part) obsolete. This change was of course a big boon to disabled users, because then a table could go back to just being a table, and there is now much less confusion for screen reader users. With HTML 5, we should see similar advancements, where more elements will be used for their intended purposes.

When a Site Just Isn’t Accessible.

When I come across a web site that isn’t accessible, I usually just leave. However, if I really want to access that site, I can often do so through the mobile interface, assuming it is available.

This work around isn’t perfect, as the mobile site almost never has all the content or features of the main site. However, limited access is better than no access at all.

The other, more serious problem I encounter when using this hack is caused by some sites that recognize that I’m using a browser on a PC. It is possible to fool the server, but it’s not easy.

The fact that this work around exists is of course no excuse for not making your main site accessible. However, if your main site is inaccessible, and you have a mobile version of your site, at the very least, don’t block it from being able to be viewed in Firefox or IE.

Remember also that a mobile site is no substitute for making your main site accessible, unless it simply isn’t feasible, you provide as much content and functionality as possible on the mobile site, and you place a prominant link directing users with accessibility needs to the alternate site.

Finally, just because a site works on a mobile device doesn’t mean that it is accessible, though the odds are much greater that it will be. Nevertheless, the standard web accessibility advice and guidelines still apply.

Requiring Right-Click Can Make Your Site Inaccessible

It’s not uncommon to see the instruction, “To download the file, right click and …”, but this can be difficult or impossible for screen reader users to do. The problem is that Jaws and Window Eyes don’t offer an easy way to right click on a link. I can do it, but it’s sometimes quite difficult, even for me, a reasonably advanced user.

If the link is text, I have to use the Jaws cursor to find the link on the screen before I can right click it. (The Jaws cursor is basically the mouse, but you move it with the arrow keys and click with the keyboard.) Just finding the link can often be a slow process.

However, if the link is an image (<a href=…><img src=…/></a>), there is no text for me to find with the Jaws cursor. The only option left to me at that point is to click on the link, quickly press ESC to cancel the page loading, and then press Shift+F10 to right click on the link. It took a lot of trial and error to come up with that procedure, so it’s a pretty safe bet that most users won’t be able to download content from these types of links.

This is a major oversight that needs to be addressed by the screen reader manufacturers as soon as possible. But in the meantime, you should avoid requiring your users to right click. If you want to offer content for download, you can either zip the file, or change the content-type sent to the browser. Zipping the content is probably the easiest option, as most web servers will automatically serve such files with a content-type which will cause browsers to prompt the user to save. Changing the mime-type sent to the browser is only slightly more difficult, and can be done with a little PHP or the server-side language of your choice. Unfortunately, I don’t know of any way to accomplish this with JavaScript, but if you do, please post in the comments.

Accessibility Checklist, Version 1

Last year, I posted an accessibility checklist on North Temple. I don’t generally like to recommend these sorts of lists, because they tend to get abused. People think that the checklist is all they need to make their site accessible. You should only use an accessibility checklist to make sure you didn’t forget anything, or to give you ideas on what to study further.

The size and nature of this checklist makes it impractical for me to provide anything more than the briefest of summaries of each topic, so if you’re relying on it as a tutorial, rather than as just a checklist, your accessibility efforts will almost certainly fall short. I of course also wasn’t able to cover every possible accessibility issue, but only the most common.

So, with the above limitations in mind, here is the Accessibility Checklist, version 1. Watch this blog for version 2, coming soon.

Accessibility Checklist


  • Separate structure from presentation and use proper markup for that structure. For example, mark up lists as lists (<ul>, <ol>, <dl>) rather than text with a <br> tag after each list item.
  • HTML headings (e.g. <h1>) are very helpful for blind users. Properly mark up the sections of a page and body copy with HTML headings rather than something such as a <p> tag with CSS styling that makes it look like a heading.
  • Give pages meaningful and accurate titles using the <title> tag.
  • Indicate the primary human language of the document using the lang attribute in the <html> tag, and indicate any passages in a secondary language using the lang attribute on other tags wrapping the relevant text (e.g. "<span lang="es">Hola</span> means Hello”).
  • Provide “Skip to content” links at the top of the markup order in pages with large numbers of navigational links before the main content.
  • Always indicate headers in data tables using <th> tags, and associate all data cells with their header.
  • Be sure tab order is logical using tabindex, if necessary. (If your HTML is in the proper order, then using tabindex isn’t necessary.)

Visual Appearance and Content

  • Be sure your page is still usable when images are turned off. (This may include making sure that contrast is still sufficient if you happen to be using a background image and that image is removed.)
  • Be sure pages remain usable when users enlarge text up to twice its original size.
  • Be sure each element on a page is reachable and can be manipulated via the keyboard.
  • Whenever possible, write descriptive headings and link texts which can be understood when read out of context (e.g. no “click here” links).
  • For color-blind and low-vision users, be sure your content and background have sufficient contrast.
  • Do not use content that flashes or blinks more than three times a second.
  • Do not hide the focus indicator. When a user uses the keyboard to tab from element to element, it should always be apparent where they are.
  • Do not require users to perceive font, color, or other styling changes in order to understand meaning. For instance, don’t say, “The highlighted word in the previous paragraph is the most important,” or “Items marked in red are errors and need to be corrected,” unless the word or items are indicated in some other way.

Dynamic Content

  • Do not use JavaScript events that radically alter the page or load a new page when fired.

Images and Multimedia

  • Be sure all images have an alt attribute, leaving the text for decorational images blank (e.g. alt="").
  • Always add alt text when images are also links.
  • In general, be brief with alt text (e.g. “the Christus statue”), but provide detail when it conveys meaning (e.g. “President Hinckley’s son standing at his graveside with family in arms”).
  • Provide a transcript, captions, and/or sign language translation for all audio and video with speech.
  • Provide a “described” version of a video when description is necessary for unsighted users to understand content. (The described audio track can either be distributed with the video content, or as an audio only file.)
  • Be sure that all videos, if they don’t autoplay, have, at the very least, an accessible Play control.
  • When text can be rendered just as well by the browser as it can in an image, avoid using images for text. (Image replacement techniques are often an acceptable alternate, but also consider translation requirements when using text in or as images.)
  • Avoid CAPTCHAs unless you have no other choice, and even then they should be avoided. However, if you must use them, provide an audio CAPTCHA alternative.


  • Always label all form fields with the <label> tag. If a form field has no specific text label on the page, add one, and hide it with CSS or use the title attribute.
  • Use fieldsets (<fieldset>) with legends (<legend>) to associate prompts with radio buttons and check boxes. For instance, a form asks “Gender:” and offers radio buttons that say “Male” or “Female”. Then “Gender:” should be enclosed in a <legend> tag, and all three elements (<legend> and the two radio buttons with their labels) should be enclosed in a <fieldset> tag.
  • Identify all input errors in text (in addition to any images or icons), and place the error notification either next to the affected field or in a prominent location such as the top of the page with an anchor link to the affected field.
  • Provide help links or inline instructions for completing fields when necessary.
  • Do not permit users to complete important actions without a confirmation or a way to undo.
  • Avoid using HTML elements in nonstandard ways (e.g. form elements for navigation, links for form submission, etc.).


  • Test all pages for markup validation (http://validator.w3.org). If your page does not pass validation, there should be a good reason for it.
  • Test all pages for color blindness using simulators or browser plug-ins. (Recommended: http://colororacle.cartography.ch or http://www.vischeck.com)
  • Test all pages for accessibility (http://wave.webaim.org), but only after you have done all you can to make sure it is accessible using the recommendations in this document.
  • Have your pages reviewed by an accessibility expert.