Category: browser

No to Text Resize Widgets

Michael Gifford (@mgifford) recently wrote a tweet on text-resizing widgets. It said:

Is it time to scrap text resize widgets and teach people how to resize text http://bit.ly/94jNkv

I totally agree. Say no to text resize widgets. To enlarge text for users, the browser should be used (many reasons below). See this video from OpenConcept on how to text-resize in your browser.

Gifford’s tweet references an article on the subject from almost 3 years ago, Scrap text resize widgets and teach people how to resize text from 456 Berea St. This site had also blogged about the topic a while back in Don’t Use Text Resizing Widgets.

Keep in mind is the issue of misinformation. For example, the very recent article A quick Web Accessibility Checklist actually encourages the use of text resize widgets, or in their words a “Font re-size option”.

Gifford’s tweet sparked many responses with many very good points, which all support why not to implement text-resizing tools on a website. I’ve summarized some reasons from very respectable professionals including @v, @alxp, @johnfoliot, and @ppatel. (Bonus! See slide 12 of Web Accessibility Gone Wild by WebAIM which also discourages the use.)

  • Implementers need to stop setting font to 80% (or lower!) in the default CSS.
  • Text resize widgets only add another layer of complexity on top.
  • Text resize widgets don’t resize text in images.
  • Text resize widgets are site-specific. There’s no standard; each site implements differently.
  • Text resize widgets causes confusion, clutters up the interface.
  • Text resizing is the responsibility of browser; browsers should do this natively. Browsers need a better way to expose this functionality to the user.
  • Users who regularly need larger text have figured this out already on all the sites that lack such a widget.
  • Interface design is not graphic design. Tyrannical control over font size & colors in UI is doing a huge disservice to users.
  • Text resize widgets make the author feel like they are doing good, but only solve problems created by the designer/developer in first place.
  • Not many users I’ve spoken to (@ppatel) use the widgets.

Accessibility for HTML5 Video, Controls and Captions

As you probably know, HTML5 provides a video tag for rendering a video natively in a web browser (and audio as well). But unfortunately, as of now, HTML5 video isn’t very accessible, yet.

Controls

Browser support for native HTML5 video controls varies widely. No browsers but Opera provide keyboard-accessible controls. Well, you can also start/stop with keyboard in Firefox 3.6. To make the controls keyboard-accessible calls for JavaScript. This is fairly easy to do, and is quite fun to implement for web geeks like me. But nonetheless it requires JavaScript which obviously isn’t good for devices and browsers which don’t have JavaScript available.

Note that in Firefox 3.6 and below, disabling JavaScript also disables the native video controls! To bring up a contextual menu, you must do a mouse right-click in the video.

Captions

The HTML5 spec has a great plan for captions, timed tracks. It accommodates well for different types of roles (captions, subtitles, descriptions) and multiple languages. The format of the caption text files themselves may be similar to the time stamp format WebSRT (Web Subtitle Resource Tracks). Sadly, there is no support for timed tracks in any browser at this time. The code would go inside the video tag and would look something like this:


Fortunately, in the meantime, Bruce Lawson of Opera provides a method for JavaScript HTML5 video captions. The solution uses JavaScript to grab caption text from span tags with time attributes and place the text over a video. Neat! If JavaScript is unavailable, the caption text appears below the video.

About the Codecs/Containers

Not directly related to accessibility, but let’s take a look at the supported video codec/containers of the major browsers. First off, and not surprisingly, Internet Explorer doesn’t support any HTML5 video. And the word is that IE9 will only support WebM if it’s installed on the operating system.

So to cover all major browsers today, you’ll need to encode to an OGG and MP4 file, and then do a Flash video fall-back for IE. Here’s a great table on current support codecs/containers.

Video support in shipping browsers
Codecs/container IE Firefox Safari Chrome Opera iPhone Android
Theora+Vorbis+Ogg · 3.5+ · 5.0+ 10.5+ · ·
H.264+AAC+MP4 · · 3.0+ 5.0+ · 3.0+ 2.0+
WebM 9* 4 · 5.0+ 10.6+ · ·

It appears WebM will be the codec of the future, but again, it is only partially supported at this time.

Related links

Free Browsers for Visual Impairment

I recently came across an article from disaboom called “Assistive Technology: Top 8 Free Browsers for Visual Impairment and More“. The link was also popular on Twitter. But one problem, there are no links to the mentioned browser! So I went and found them:

  1. WebbIE -accessible browser, RSS news reader and more.
  2. EdWebtalking web browser that can display web pages as text and symbols.
  3. Fire Vox – Talking Browser Extension for Firefox (add-on page).
  4. CliCk, Speak – less advanced version of Fire Vox.
  5. Orca – speedy and powerful Gecko-based browser.
  6. Simply Web 2000 – outdated; optimized for Internet Explorer 5.
  7. SpeakOn -PC-based media suite program (four apps).
  8. Thunder – package contains the WebbIE Text browser and more.

I’d like to add that Disaboom is a pretty nice site. In their words:

Disaboom is the leading resource for disability information and real-life articles about people with disabilities. Our broad range of topics, including health conditions, lifestyle, and helpful resources, help you create the life you want.

Don’t Use Text Resizing Widgets

Web sites should not implement text resizing widgets–you know, those little buttons, usually an “A+” and “A-” that increase/descrease the size of the text on the site. The responsibility for providing this functionality lies with the browser, like the forward and back buttons.

Web designers/owners need to put forth more effort in teaching/guiding the user to using the browsers’ features for text resizing. Equally, the browsers themselves should make this feature more obvious and usable.

In addition, most sites I see that use resizing widgets are not very accessible; they seem to add this feature as a cheap replacement (bluff, excuse) for a genuinely accessible web site.

More:

Selecting an Accessible CMS

Here’s a good article from Juicy Studio on choosing a CMS with accessibility and other considerations in mind. The highest ranked were Quick and Easy, Plone, and Drupal (with “some customisation”).

The criteria used in the testing were:

  • functional, accessible and usable to authors with minimum experience
  • an accessible Web content management solution on a limited budget
  • the WYSIWYG editor should be accessible to screen reader users (JAWS and Window Eyes), and easy to use

The CMS’s evaluated were:

  • Jadu
  • Mambo
  • Joomla
  • Quick and Easy
  • Expression Engine
  • Plone
  • Drupal
  • Textpattern
  • Xoops
  • Typo3