How Accessible is Safari?

Note: The content of this page is very much out-of-date and may no longer be relevant or correct. It is kept here for little more than archival purposes. Please bear this in mind before reading on.

Posted on: 07 February 2003

Prologue: this article was written before build 60 was released. Many of the issues raised were fixed in that release of Safari. Please check the links at the foot of this page for an update on this.

When Apple released Safari on to the unsuspecting world earlier this year, it caught a lot of people off guard. The ripples are still being felt - Mozilla's source code was rejected in favour of the smaller code base of KHTML, and more recently Opera has suggested that it may no longer make a version of its browser for the Macintosh platform. And then, of course, there's the whole issue of how web developers can keep up with yet another browser foisted upon them - does it support agreed web standards? Or does it break standards-compliant sites in horrible new inventive ways?

This prompted me to ask the question about how accessible Safari is - how well does it support HTML or CSS features that can be used to comply with the W3C's Web Content Accessibility Guidelines?

Mac Accessibility in general

Not so long ago, I chanced upon a site (whose URL I didn't store) that was evidently written by Mac developers, or more specifically Mac OS developers. On that site I read a quote along the lines of "the Macintosh operating system has always been recognised for its excellent accessibility features." It then went on to detail how good the native text-to-speech (TTS) engine is, but it was hardly an impartial view. The fact is that there is very little in the way of assistive devices that work on the Macintosh platform - using screen readers as the (usual) example, how many can you name that run on the Mac platform? Jaws, Window Eyes, IBM Home Page Reader - to name but a few - are all PC-based. So, this begs the question - "Why should the developers bother putting in accessibility hooks if there is nothing that currently hooks into it?" This is not my argument - it's an argument I imagine others putting forward, and it's all wrong. It's no different from the arguments that flew around during the 'browser wars', i.e. "Why bother introducing support for some W3C standard when we don't believe anyone is gonna use it? Hey, let's do our own thing - let's introduce something called a <layer> and forget about <label>."

It's a catch-22 situation, but the battle for support for web standards in the browsers is almost won, largely thanks to the pressure placed on the browser vendors by the webstandards.org (AKA WaSP). So, while there may be few assistive devices that can be used on the Mac, that doesn't mean that there shouldn't be the option for someone to try to develop a new one - but they can't do this if the support - the hooks - are not made available.

So, what do we know about Safari's support for accessibility so far?

Features known to be unsupported in Safari

The list so far looks like this:

Keyboard Navigation is not supported.
1. The accesskey attribute is not supported
2. You cannot tab to links or most form elements
Some form elements are not properly supported
1. <label> ?ot supported (demo)
2. <fieldset> and ?ot supported (demo)
3. <legend> ?ot supported (demo)
The title attribute is ignored (demo)
Table accessibility is severely limited
1. The tfoot element is rendered before any tbody (demo | (screenshot of expected behavior | screenshot of Safari's behavior | discussion)
Aural browsing
1. The summary attribute is not spoken
2. The <th> abbr attribute is not spoken
3. the <img> longdesc attribute is not spoken
Does not support the <q> element (for inline quotations).

In addition, it's not entirely sure how Safari handles the lang attribute. Not sure what this lang thing is? Here's what the World Wide Web Consortium has to say about lang.

Language information specified via the lang attribute may be used by a user agent to control rendering in a variety of ways. Some situations where author-supplied language information may be helpful include:

Assisting search engines

Assisting speech synthesizers

Helping a user agent select glyph variants for high quality typography

Helping a user agent choose a set of quotation marks

Helping a user agent make decisions about hyphenation, ligatures, and spacing

Assisting spell checkers and grammar checkers

And given what we already know about the lack of support for screen readers, it's probably safe to suggest that the support is not going to be great (if it exists at all!)

Keyboard Navigation

Most browsers allow users to navigate between links and form elements with the tab key. This is known as keyboard-based navigation. Users with motor and visual impairments rely on this.

Safari supports tabbing, but only to text-input form elements. For those elements, it even supports the tabindex attribute. Tabbing to other focusable elements (e.g. anchors, checkboxes) is, unfortunately, not supported. Like most applications, Safari supports spacebar for page down and arrow keys for line navigation. Safari also has one proprietary keyboard navigational feature: Apple Command Key n takes you to your n^th bookmark.

Usability is directly contingent upon keyboard accessibility. Everyone benefits from keyboard accessibility. Users with some physical disabilities may have little or no manual dexterity and/or increased tendency to push unwanted buttons or keys. These users rely on keyboard navigation because using a mouse is difficult or impossible. Users with visual disabilities also rely on keyboard navigation because it is difficult or impossible to track the cursor. Users with no impairments also benefit from keyboard navigation because keyboard navigation is easier, more convenient, and less strenuous on the hands.

Imagine filling in the text inputs of a form but not being able to navigate to any checkboxes, radios, or the submit button? I invite you to try it to see just how frustrating it is.

HTML 4 form elements in Safari have even more problems which I'll discuss next.

Structural Form Elements

The <fieldset> and <legend> elements identify and extricate groups of form elements. The fieldset element structurally groups form elements while the legend element labels such fieldsets.

Safari supports neither the <fieldset> nor the <legend> element.

Aural Browsing

Some users require a screen reader. This reader interprets the document and presents its content and structure to the user in a spoken format.

Apple's Speech is found under the Application menu. In Safari, it is the under Safari > Services > Speech > Start Speaking. Safari does not offer a keyboard shortcut for Start Speaking, but iCab does (Apple Command Key 9 to start speaking and Apple Command Key shift - to stop speaking)

Safari requires a text selection before speech will work. Speech starts at the top of the selection and reads to the end of the selection without pause. This requires that the user perform a special cursor technique of click-hold-drag-scroll-release to obtain a selection. This technique takes time with long documents, but is usually more desirable than select-all because select-all also selects navigational links.

Safari will only speak rendered text. That is to say, Safari will only speak text content that has been parsed and rendered on the screen. This is problematic in many ways.

When navigation is structurally included last in the document and then positioned at the top of the document with CSS, Safari will speak the navigation first. This is almost never desirable.

The longdesc of the <img> element provides users with visual impairments access to alternative content. When the longdesc of the img element is found, the screen reader is supposed to either download and speak that text or allow the the user to pause the text in the current context of the page, download, and then speak the text. Safari ignores the longdesc.

The abbr attribute of the th element is for abbreviating long table headers, such as "Scholastic Achievement Test" to SAT. This allows the table headers to fit visually on a page while also providing a structural and semantic alternative for assistive technologies (e.g. screen readers). Safari does not support this attribute.

The <abbr> and <acronym> elements are ignored by Speech in Safari, as are the phrase elements <strong> and <em> as are all other structural and or semantic elements. Safari uses Speech to speak rendered text.

The thead and tfoot elements provide structural groupings for table elements.

The HTML table element was designed to represent relationships among data ("data" tables). Even when authored well and used according to format specification, tables may pose problems for users with disabilities for a number of reasons:

Users who have serial access to content or who navigate sequentially to a table may have difficulty grasping the relationships among cells, especially for large and complex tables.

Users with cognitive disabilities may have trouble grasping or remembering relationships between cells and headers, especially for large and complex tables.

Users of screen magnifiers or with physical disabilities may have difficulties navigating to the desired cells of a table.

Safari does not support the <tfoot> element.

Summary of Safari's Accessibility Support

In short, Safari makes it difficult - if not impossible - for anyone with a screen reader to use the web. For people who prefer to use keyboard shortcuts for speed (or perhaps because they have motor deficiencies that make moving a mouse around problematic), Safari is not at all helpful.

Although Apple has been supporting its own text-to-speech since classic, it has not yet been effectively integrated into Safari. This is a shame, given that the Macintosh speech engine sounds markedly better (to my ears) than that used in Windows.

So, while we can all get a little excited about a new browser development, about how cool it looks, about how well it manages bookmarks or whatever, the truth is that there is still work to be done to make the browser usable for a wider audience.

Feedback on this article

Safari is a new browser and as such many bugs will be fixed in subsequent releases. This might be true for accessibility oversights also. There may also be more problems with the browser not noted here - if you do spot anything, please drop us a line using the Contact Us page.

Finally, there may be features in Safari that positively improve some aspects of web accessibility. If you have any of these, please let us know what these may be and the article will be updated accordingly.