Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. Next in the list tends to be availability of functionality: progressive enhancement for client-side scripting, ability to navigate the page via skip links or semantic HTML headings, and so on.

But what about the content itself?

Disregarding issues concerning the use of abbreviations, typography, headings, and other semantic structures in HTML, the simple use of punctuation can be a significant barrier. This is a problem which applies to all text content for any user of a screen reader, in particular, although following these suggestions will benefit any reader of your content.

The issue isn’t precisely correctness. A sentence can be punctuated with perfect correctness but still lose clarity when spoken by a screen reader. It’s a matter of the lack of refinement in screen reader voice interpretation.

As a human speaker or writer, aware of the meaning and context of a sentence, it’s easy to speak a sentence and convey the meaning you expect in that sentence. A slight emphasis on one word or another is highly significant. However, in HTML, as in normal writing, there’s no means to indicate this kind of special emphasis which is readily understood by current screen reader technology. As important as strong and emphasis are semantically, they are not interpreted meaningfully by screen readers.

Punctuation is left as the sole means to refine and polish the meaning of a sentence for screen readers.

How do screen readers use punctuation?

Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character. Web AIM, “Designing for Screen Reader Compatibility”

So common sentence punctuation marks, such as periods and commas, are indicated by pauses. However, special punctuation, including dashes and parentheses, are read as characters. This should immediately tell you how difficult it could be to understand a sentence containing numerous subclauses or parenthetical statements!

Only a few years ago, it was common to see pages that explained quote this page best viewed in Internet Explorer quote left paren or Netscape right paren. Web AIM, “Designing for Screen Reader Compatibility”, as rendered by Fangs

Although this is a relatively simple example, containing a single quoted passage and a single parenthetical statement, it could readily be very confusing to follow a more convoluted sentence structure, regardless of the correctness of the sentence.

So what’s the solution? Simply speaking, to write simply. Keep your sentences on the short side, avoid excessive parenthetical statements, and avoid excessive subclauses. Above all, try reading the sentence without giving any particular emphasis to the terms and see how easy it is to understand the statement. It’s easy to write an ambiguous sentence if you’ve assumed it will be pronounced in a particular manner.

Ultimately, the expectations when writing with a screen reader in mind aren’t that hugely different than without. After all, it’s not as if you intend to write confusing and ambiguous statements. However, the line drawn between “confusing” and “clear” is not necessarily in the same place for a computerized reader.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Best Practices: Writing for Accessibility

Hat tip to Henny Swan.

“WebAnywhere” is a new screen reading product (available in May of 2008) from the University of Washington and the WebInSight project. The basic concept is simple: it’s a web-based service which provides a proxy service as a screen reader. Fantastic tool for anybody requiring a screen reader at a computer which they don’t control: at a public library, a friend’s house, or any imaginable situation where your normal setup isn’t available.

The project is designed with minimal requirements, and is supposed to be usable from any web-enabled device with a sound card.

On top of that, the software is open-source and available through Google Code.

It’s impossible to say at this point how the user interface and power available to the screen reader will compare to a mainstream screen reader. Will this be a usable tool for web developers to use as a testing device, for example?

The project information is available at the WebInsight project page. The principle feature is a demonstration video, showing the basic use and value of the service.

There’s no information available concerning the features of the service beyond a few comments during the video concerning keyboard shortcuts. I’m looking forward to seeing the service and discovering what tools and features it provides.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

WebAnywhere: a Screen Reader On the Go

My overall reaction to this book was positive. It covers a wide variety of key issues for mobile web programming in an easily understood manner. The book is targeted primarily at developers who already have some experience at web development and design, so it doesn’t delve into any serious detail when it comes to server-side programming or HTML coding, but instead makes a point of emphasizing places where the mobile web is different from internet interaction on a desktop device.

Mehta goes out of his way on many occasions to emphasize the serious importance of considering who (and what!) will be using your mobile web application.

“Any website accessed from a mobile device is mobile web — whether it’s been tailored to work on a mobile or not!” Mobile Web Development, Nirav Mehta, page 10

The book covers a wide range of issues — from developing for mobile devices using a “lowest common denominator” plan to implementing highly dynamic mobile applications which adapt automatically to the device currently in use. The text is easy to understand and follows a logical progression, starting with the mobile web development practices which are most similar to the development of standard web applications before moving into the areas which are very specifically targeted towards mobile devices.

This isn’t to say that the book doesn’t have a few flaws. I identified three areas where I really would have liked to seen better work.

Editing

In general, the copy editing on this text was pretty poor. The editing improved as I got further into the book (or I became more oblivious to it), but the introductory chapters had a lot of problems. There weren’t a lot of typos — but the grammar was noticeably lacking. The book is rife with sentences like this:

“We will need a recharge of patience if we wanted to watch a movie preview on low speed mobile networks.”

I’m not a member of the grammar police, but I’m certainly sympathetic. Professionally published books simply shouldn’t contain the kinds of errors found in this book.

Code Examples

The author talks about following web standards as a critical element of mobile web development. That’s great. It is, however, a serious pet peeve of mine to see code examples which don’t reflect the text of the book. The very first code example in the book is this:

<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css">

The text preceding it states “Here’s how you can add an alternative stylesheet link in your XHTML page.” I see a problem here. Yes, the author does explain at a later point in the book that all XHTML elements must be closed: but it’s a simple fact of life that most people referencing this book will be far more likely to simply reference the code as is. This is simply a mistake; but it’s not one that should have made it through a review of the book.

I’ll admit that I haven’t gone through and checked the validation of every code example. Most of them seemed solid and accurate. There are definitely examples which wouldn’t be valid under the XHTML DocType, but I’m not adept enough with XHTML-MP to know off-hand if the same is true within the mobile profile DocType.

Appendices

Simply put, there aren’t any. There were numerous points in the book where I thought to myself that an appendix would be great. A list of resources cited by topic, a section summarizing the syntax of VXML, tables showing the differences between XHTML and XHTML-MP or between CSS and WCSS. These kinds of resources would have been tremendous benefits to the overall reference value of the text.

Overall

This is a worthwhile book. Even though I wouldn’t recommend trusting the code examples, the truth is that you should never simply take code examples as written — you learn best by taking an example and re-purposing it for your own needs. Mobile Web Development will introduce you to the key issues for mobile web programming and design in a manner which can give you a quick start on mobile web application development.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Review of “Mobile Web Development”

Example Poll

Download the .zip archive

It didn’t quite take 2 years, at least. But very, very close. The last release of this script was May 25th, 2006 — so I made it just under the wire. But this is also a bit more than just a script update. In fact, this is a complete overhaul. I’m not certain that there’s actually a single line in the poll script which is the same as the previous version.

This was necessary; because the previous version was, in a word, pretty lousy. It may have acted as a decent jumping off point for some beginning programmers to code their own; but, on the whole, it was not a sophisticated script, and it was nothing like developer-friendly.

This new version, leveraging the power of Google’s Chart API and some clever scripting by Christian Heilmann provides a better end result with fewer potential problems for the user.

I’ve vastly increased the flexibility of the script — which once could only support a fixed 2–5 options in a single question — to provide support for any number of questions with any number of options, customizable at the question level. I don’t anticipate that anybody will be authoring 100 question polls with this…but they could, in theory.

And, to cap it all off, I’ve added an administrative interface which allows users to perform most of their basic management needs without needing to crawl into the database. Hopefully, it won’t prove to be too buggy.

Are there likely to be bugs in this? Yes! So, if you download this and try it out, please let me know what you notice. I caught quite a few; but I think it’s safe to say that there are a few left in there.

And by “a few,” I mean “actually, there could be a lot of ‘em.”

Check it out or download the package now.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Long-awaited update to PHP/MySQL poll

This is part 2 of 2. Part 1 is Why use Semantic HTML?

This guide only deals with elements which have a specific, human-readable meaning. The semantics of elements such as link, which are not seen in normal browsing, have been left out, as have replacement elements like img or object. In some cases, I’ve also addressed specific attributes which are critical to providing semantic value to an element.

This is not a guide which demonstrates the opinion of the W3C as represented in the HTML, XHTML, or HTML 5 specifications. This is a practical-use guide which indicates my reasoned opinion concerning the best use of each element.

Core Block Elements

div

The div element represents a discrete section of a page which can be meaningfully divided from the content around it. Commonly used to indicate a header region, footer, sidebar, or navigation region; it’s use can extend equally to indicate columns on a page or sections of an article. The element is also commonly used in multiple layers to group lower-level sections together, such as a “content” section which groups a main article, comments on that article, and meta data about the article or author.

h1-h6

The six levels of headings are all used to introduce sections of content (containing p (paragraphs), div (page divisions) or other content) which they describe. They’re perhaps most accurately compared to the structure of an outline: h1 is the top level heading element. The only heading element which can follow an h1 is h2. h2, on the other hand, can be followed by either an additional h2, if the sections are equivalent and both fall under the preceding h1 topic; an h3 if the following section is logically a child of the h2, or another h1 if the following section is a new topic of the same level of specificity as the first heading. A common preference (although certainly not mandatory) is to use only a single first-level heading on any page and to require all subsequent headings to descend from it.

p

The paragraph element is the fundamental building block of prose text. It is also the most appropriate element for marking up a stanza of poetry or other similar discrete block of text. Different from a div principally in that it is specifically intended to indicate text regions, whereas the div element is more broadly specified.

blockquote

This is a very specific use element which should be used to indicate a significant block of text which is being quoted from outside the current source. It should always be paired with a cite element to indicate the quoted source. It may also, optionally, use the cite attribute to contain a URI for the quoted text.

Supporting Inline Semantic Elements

a

When accompanied by an href attribute, the anchor element indicates either an external resource (a resource other than the current document) accessible via hyperlink or an anchored location within the same document. Using scripting, it can be used to perform more complex functions within the current page, but should always maintain a fall-back functionality to retain it’s semantic value.

abbr

The abbreviation element generically indicates a shortened form of a more extensive term or phrase. It is inclusive of an acronym, although the lack of support for abbr in Internet Explorer frequently forces developers to ignore that relationship.

acronym

“Acronym” refers to a subset of abbreviations characterized by their formation from parts (letters or syllables) of the words they are used to abbreviate. The definition isn’t strictly agreed on, but it’s generally agreed that abbreviations formed by the removal of letters from a word are not acronyms.

em

Indicates emphasis. “Emphasis” is a general indication that the emphasized text is in some way more significant than the text surrounding it. Whether a piece of text should be emphasized or not is usually dictated by authorial preference.

strong

“Strong” is described officially as “Stronger Emphasis.” So, practically speaking, it’s an element you use in much the same scenario as you would use em: an authorially determined preference for emphasis.

address

According to the W3C, address indicates contact information relevant to a specific document or part of a document. In practical usage, it’s more commonly used to indicate any block of contact information. As a block-level element, it’s generally reserved for significant blocks of information, rather than being used to mark-up a single e-mail address or telephone number.

cite

A citation is fairly broad, and does not necessarily have to be associated with specific quoted information (although the reverse is not equally true.) cite is associated with bibliographical information, personal quotations, or references to an external resource used in the research towards preparing a document.

code

Indicates a sample of programming code as a general rule. The W3C specifications are clear that this is intended to refer to computer code; and I haven’t yet come across a situation where I needed to post encryption information which was not computer code.

dfn

This is one of the more difficult to define elements — which is ironic, given that it’s intended to represent the “defining instance” of a term. It is not intended to contain a definition, it is merely intended to enclose a term at the point in a document where it is used in a definitive state. Sounds very legalese, to me.

del

Represents information which has been deleted from a document. This should generally be used with date and time information indicating when the change was made, which can be included in the datetime attribute in the following format: datetime="YYYY-MM-DDTHH:MM:SS". See also ins

samp

Sample output from programs or scripts. Differentiated from code in that the output of a program may not itself be code, but should still be indicated as an example of output.

span

A generic inline-level HTML element. It should not be concluded that span does not contain any semantic value, rather, that it is available to be used when no other element provides suitable meaning. It is preferable to use a generic element and define a meaning for it rather than use an element which has a pre-defined and inappropriate semantic meaning.

ins

The opposite of del, above. Represents inserted text following revisions.

q

Indicates a shorter, inline quotation. Unfortunately, support for the q element is minimal, and it cannot be readily recommended for any use.

kbd

Indicates text to be entered by the user. Rarely used, but useful in circumstances where you are demonstrating the use of a program, along with code and samp.

sub/sup

Superscripting and subscripting of text can be used to indicate footnote references, valence numbers in chemical formulas (such as Fe⁺³), etc.

var

Along with code, samp, kbd, the “variable” element indicates a variable (or program argument.) It should be reasonably obvious at this point that this language was designed by programmers and not by librarians.

List Elements

ul, ol, li

This is pretty straightforward: lists are used to represent grouped information best represented as a list. ul is unordered, and is generally visually represented as a bulleted list. ol is ordered, and is generally visually represented as a numbered list. It’s common to attempt to apply lists at a significant macro level in organizing the elements in a form or, occasionally, within an entire page, but it’s my opinion that this kind of usage is taking the semantic construct a bit too far.

dl, dd, dt

A definition list literally indicates a list of terms (dt) with their accompanying definitions (dd). Practically speaking, it’s reasonable to use the definition list format for any collection of data characterized by paired relationships with one signifying and at least one descriptive. It’s perfectly reasonable to provide multiple definitions to a single term. Frequently asked questions pages are commonly assembled this way.

Table Elements

table

Oft abused, the table is the best way of organizing and displaying a data matrix. Any kind of two-dimensionally represented data should be organized within a table.

thead

Defines a header region for a data table, which would normally contain the headers (th) for each column.

tfoot

Defines a footer region for a data table, which should include information referential to the columns of data.

tbody

The content bearing region of a table, but also includes row headers.

caption

Briefly describes the table. This is essentially a heading for the table.

th

A heading for either a row or a column, to indicate the type of information within that row or column.

td

A data cell, in which content is placed which corresponds to both the headers for the row and column.

Attribute: scope

Scope: applied to th, it indicates whether the heading information applies to a row or a column. It can also be applied to a row group, for tables which have been divided into multiple sections.

Attribute: headers

A much, much, more complicated way of indicating relationships between data cells and their respective headers. Necessary in complex tables where a given data cell may apply to multiple row or column headers. If possible, just avoid creating tables which are that complex…they’re a headache.

Attribute: summary

Applied to the table element, the summary is a more extensive description of the table, intended to provide non-visual users with the equivalent of a “quick scan” of the table to best understand the purpose it serves.

Separator and “Other” Elements

br

Generates a line break. The semantics of a line break are a commonly debated point - you can read my views in my article “Is a br tag semantic?“

hr

Separates two sections with a visible horizontal line. Although this element conveys no specific semantic meaning which is not conveyed by other elements, it provides the advantage of a visual separator between sections when styles are disabled which is otherwise unavailable. I’m not aware of any advantages for other scenarios.

Discouraged (Presentational) Elements

These elements have not been deprecated; but should generally only be used after careful consideration.

• big
• small
• b
• i
• tt
• pre

Is it semantic, or is it presentational? This can be a more difficult question than it initially appears. Take b. Presentationally, it renders text as bold. Semantically, it provides no specific emphasis or other specific meaning. Does this mean that it should never be used? Not clearly. Although it’s difficult to describe scenarios in which these elements are useful, if you assume a scenario in which you want bold text but do not want that text to receive additional emphasis, it makes more sense to use b than it does to use span and style it to be bold.

Regardless, these are not elements that should generally be used without careful consideration that they are, in fact, the best choice for the job. But it’s your call.

Deprecated Elements

• applet
• center
• font
• dir
• isindex
• menu
• s
• strike
• u

Not all deprecated elements are created equal. I find it ironic that strike and u are set right alongside font and isindex. Thinking logically, strike and u are very much in the same vein as b and i. Presentational, but perhaps necessary in some contexts.

Nonetheless, there’s no way I’m going to recommend the use of deprecated elements. Find another way!

If you want to see these elements in action, you may find my semantic HTML graphing tool interesting.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Guide to Semantic Use of HTML Elements

This is part 1 of 2. Part 2 is my Guide to the use of Semantic HTML Elements

I’ve seen a lot of articles discussing the importance of HTML and XHTML semantics. I’ve seen articles describing what it means for a document to be semantic. Most of these articles, however, don’t provide a serious overview of what HTML elements actually may be considered semantic — and what those semantic elements actually mean.

And, even more particularly, why it matters.

Semantics is an erudite area of study. Literally, semantics can be fairly defined as the study of meaning in communication. Communication can readily be extended to cover symbolic notations, representations of language, organization of language, body language and information structures. In developing a web page, we are organizing a means to communicate the content of that page: ideally, we are organizing the page in such a manner that it will be understood regardless of the method by which the page is accessed. It should be equally understandable whether seen, heard, or felt.

The semantics of HTML structure, then, are clearly an important part of web design. Sending mixed signals to the user agent or the user by using a blockquote purely for it’s native indentation is an abuse of semantics: even the visual impact is dependent on the assumption that user agents will consistently render a blockquote in an indented manner.

It’s not precisely an issue that you’ve used a semantic element for presentational means, because, in fact, you’ve done more than that: you’ve presented a block of text which is not quoted material as if it were.

Semantic elements of HTML carry meaning regardless of your knowledge of that meaning. The result is that the misuse of an element creates the potential to mislead or confuse an end-user.

The most obvious examples in common use are those which make use of elements with semantic meaning which also offer a browser-contributed default presentation in order to use that presentational style. The blockquote example above is not uncommon; similarly, the use of empty p elements to create extra white space or heading elements used as a questionable SEO technique in substitution for normal paragraphs.

Other examples which bear mentioning include the use of empty anchor elements to trigger Javascript events — in this case, it’s partially a limitation of the identity of an anchor element, but an empty anchor element should always be considered an error, as it results in a behavior-less anchor if the Javascript is not available.

Now, you may point to the following paragraph, from the HTML 4.01 specifications, as a response to my opinion:

Authors may also create an A element that specifies no anchors, i.e., that doesn’t specify href, name, or id. Values for these attributes may be set at a later time through scripts.

The fact that it is allowed by the specification does not make it a best practice. With all due respect to the W3C, this should not be permitted. For reference, the HTML 5 specification currently reads:

If the a element has no href attribute, then the element is a placeholder for where a link might otherwise have been placed, if it had been relevant.

In addition, although I won’t quote everything, the specification states that an anchor which does have the href attribute must specify a URI as the value of that attribute. It appears to essentially state that an anchor element should have no semantic meaning if the href attribute is not set and valid. But I could be wrong.

The best means to avoid the misuse of elements is to have a clear understanding of when and why a given element should be used in web development. To hopefully expand on your knowledge in that respect, I’m attempting to provide a semantic guide to HTML elements for your reference and rich disagreement.

Be aware, however, that semantics are largely a matter of opinion. It’s not a question of blindly following the guidelines set by a group; it’s a question of interpreting those guidelines to the best of your ability and belief. This guide reflect how I think HTML elements should be used; and I welcome your opinions.

Other HTML Semantics Articles

• Guidelines from WCAG 2.0 on the use of HTML for semantic structure
• Traditional HTML Semantics (Part I of a three-part series on web semantics by John Alsopp)
• HTML: The Foundation of the Web - Niels Matthijs
• Semantic HTML and Search Engine Optimization - From the Opera Developer Community, by Joost de Valk
• Who will read your semantic HTML? - Jesse Skinner
• When semantic markup goes bad - Matthew Paul Thomas
• Semantics - why bother? - Mel Pedley at Accessites
• HTML Semantics from Western Civilization, Pty.
• Graph the Semantic HTML Structure of your Web Page - Joe Dolson

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Why use semantic HTML?

“Sitelinks” are additional links Google generates from the contents of a site in order to help users navigate your site — they provide these links in their search results for selected terms. Most sites don’t have site links, so I’m finding it pretty cool to notice them for myself!

If you can’t see the image, the current Sitelinks for this site are:

• Gallery
• Blog Home
• What is Web Accessibility
• SEO and Accessibility
• Articles

On the whole, I’m pretty pleased with the selection chosen here. They’ve pretty well pinned down the key areas of the site: web design, web accessibility, search marketing, and my writing on these topics. Everything is reasonably represented. Perhaps, in my forthcoming site redesign (don’t keep a look out; it’s not going to be that soon,) I’ll make a point to better promote these specific areas of the site.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Google Site Links for “Joe Dolson”

In fact, cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.

“Compatibility” (in this context) is not a term which means “looks and behaves identically” — instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.

Of course, let’s be honest: there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They POP their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6 after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…

Another good reason is that despite what I’ve stated above, making the design behave more-or-less identically between different browsers is actually quite desirable. From a usability perspective, a seamless change in interactivity between different user-agents is very desirable. If you’ve ever tried to guide somebody through using a website which delivers a different experience to their browser than to yours, you are intimately familiar with one reason it’s a very bad idea.

But the absolute key to cross-browser compatibility is simply functionality. A lack of cross-browser compatibility doesn’t mean that something looks different; it means that it doesn’t work.

And a good thing, too. Otherwise, compatibility would be pretty well impossible between desktop browsers and mobile browsers.

With web design, it’s occasionally entirely possible to make two browsers render a design exactly the same…if you assume certain factors will remain constant, such as the user settings described in my last post. If any of those have been changed, everything pretty well goes out the window. As desirable as it is to make your designs look as similar as possible between the various desktop browsers, it always has to be acknowledged that there are limits.

There’s nothing at all that you can do to actually guarantee the same view for everybody; instead, you need to guarantee an equivalent view for everybody. Equivalent in that they will be able to get the same information and use the functions of the site to perform the same actions.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

What is “Cross-browser compatibility?”

In fact, browser’s allow you a great deal more control than simply size. Modern browsers can give you extensive control over website text, including dictating background colors, text color, base text size, minimum text size, and link attributes. This post is intended to provide a quick overview of the specific controls for most modern browsers.

Most browsers have fundamentally the same options, although the interface and location in menus is quite variable. Some are more intuitive than others, and some interfaces simply don’t quite work right…

• Firefox, versions 2 and 3, Netscape 9
• Opera 9
• Safari 3
• Internet Explorer 6/7/8
• Internet Explorer, features specific to versions 7/8
• Internet Explorer, features specific to version 6
• Custom Stylesheets

Firefox, versions 2 and 3

Main Options: Tools » Options » Content

Options for text configuration in Firefox are split between three menus, as is the case in most browsers. In addition to the basic options (setting your default font and font size), you can open up menus to configure preferred browser colors, link behavior options, etc.

Advanced Options: Tools » Options » Content » Advanced

In the advanced menu, Firefox gives you the options to set preferred fonts for Proportional, Serif, Sans-serif, and Monospace fonts — this can be useful, if you know what they mean, but is primarily a decorative decision. However, they also give you the ability to set your minimum font-size AND to dictate whether or not web pages will be allowed to over-ride your own browser settings for font face. The minimum font-size can be a very powerful tool for accessibility — it allows you to easily prevent any website from ever producing text at a size you are unable to read.

Color Options: Tools » Options » Content » Colors

Text color options are fairly straightforward. Firefox doesn’t provide an extensive list of choices: you have only four generic objects you can choose color for. Links, visited links, text, and overall background. Importantly, however, it gives you the power to enforce your choice of text and background colors, overriding any web site text or background colors. (For the record, it does also override background images, so no worry that you’ll be left with black-on-black purely because the site is using an image for the background text.

Netscape 9 uses the same options menu as Firefox, and this will not change, since Netscape was officially killed as of March 1st, 2008. RIP, Netscape.

Opera 9

Basic Options: Tools » Preferences » Web Pages

The options in Opera 9 are much the same as Firefox, with a significantly different organization — and a couple of glaring omissions. The first omission noted is that while Opera provides you with the option to change the default background color, it does not give the option to change the corresponding default text color. This could easily cause problems, and makes it much more difficult to choose as your preference a light-on-dark color scheme, for example. The second omission is the lack of an option to have Opera override the text colors set by the web site. The options provide are merely to configure pages without a specific style applied — leaving you with less than ideal options when it comes to preferences on a less than ideal site. In general, the basic options are extremely weak in Opera.

Advanced Options: Tools » Preferences » Advanced » Fonts

The advanced options in Opera, while providing extensive options for configuring font colors, sizes, and faces, are perhaps a bit confusing to operate. They may be a bit on the overwhelming side for some users. However, they do also give you a lot of choices. You’re presented with a list of 23 separate types of on-page text which you can modify. Rather than simply setting one base font size or face, you can individually configure settings for browser menus, toolbars, web page text, headings, and form input.

The one complication is that not all fields give you the same set of options. While at first glance, it’s very nice that they provide options to change browser menus, in fact they have not provide the option to change the text size for those elements. Ah, well. The menu to configure those text elements which are fully configurable is straight-forward and logical.

How these text presentation choices actually function, however, is perhaps a little bit mysterious. It’s not 100% accurate to say that these are choices specific to text elements. The organization doesn’t make this clear, and there’s no text to describe it, but if you change the option “Web page normal text,” this will effect all text on the page. This option appears to be inclusive of all the element-specific configurations expressed below. Changing this option will override whatever text-size choices the website has made. This is not apparently true of the other options: changing the specified size for h1 did NOT override the website specifications in my testing.

Safari 3.0 for Windows

Main Options: Edit » Preferences » Appearance

The basic options in version 3.0 of Safari are pretty simple, at first glance. You can pick the basic options (font face and font size) for standard and fixed-width fonts. If you want to change the default font size to one of the options provided (9-14, 16, 18, 24, 36, 48, 64, 72, 96, 144 or 288 pixels), you simply select that size and you’re set. If you want a size not in that list, however, you’re in for a surprise.

First, Safari 3 for Windows does not provide any kind of control to save or commit your changes. They are intended to be committed immediately, with no need to save. This is counter-intuitive in the Windows operating system paradigm, particularly when making a change which is not immediately visually apparent. In the case of font changes, fortunately, as long as you have a web page open behind the control panel, you will see the results immediately.

But…if you type in the size you would like to see (in the editable text field in the upper right corner), it does not immediately take effect. This is because the change is actually implemented as soon as you remove focus from the text box. So, if you edit the text box manually and then close, the change will not be saved. If, instead, you edit the text box and then move the focus to any other field, your edit will then be committed.

The other option for freely changing text size is a vertically oriented slide control. This would be reasonably logical if it weren’t for the list of font sizes right next to it — the select control is listed from smallest to largest, but the slide control moves the opposite direction: the largest sizes at the top. Still, once you get the hang of the controls, it’s not difficult — just not really intuitive.

Advanced Options: Edit » Preferences » Advanced

The Safari advanced options provide only one additional text refining feature: the ability to set the minimum font size rendered. This is also where you can attach a custom stylesheet; but this type of feature will be discussed later. You may also note at this point that Safari offers no options for altering text colors, background colors or link colors.

Internet Explorer 6/7/8

Main Options: Tools » Internet Options » General » Fonts

The general font options in all version of Internet Explorer are quite basic — the only option available is to choose the font faces which will be provided for web page or plain text fonts. Straight forward, simple — and doesn’t do very much. For the most part, this is not likely to provide any additional accessibility, unless you happen to spend a lot of time on the web sites which have not specified a font face and have difficulty reading Times New Roman.

“Accessibility” Options: Tools » Internet Options » General » Accessibility

I put this section into quotes because I find the categorization of these options as being specifically “accessibility” options is a bit specious. What is actually provided under the accessibility menu are the options for allowing Internet Explorer to use your color and font settings to override web site settings. It should be noted that Internet Explorer allows you to ignore the font sizes specified on a web page, but does NOT allow you to change your own base font setting. (You can change this setting in your Windows appearance options, and it will effect web pages if the “Ignore Font Sizes” setting is checked.)

One sadly missing feature in all versions of Internet Explorer is the ability to set a minimum font-size — a feature which, in my opinion, adds great value to other browsers.

Internet Explorer 7/8

Colors Options: Tools » Internet Options » General » Colors

With Internet Explorer 7 and, so far, version 8 as well, the color choice menu has been redesigned from version 6. It has not been designed for the better, mind you. The interface is, to say the least, confusing. There are two check boxes in the new interface: “Use Hover Color”, and “Use Windows Colors”. “Use Hover Color” is fairly straightforward, although the way the interface is designed makes it unclear what color will in fact be used.

“Use Windows Colors,” however, is quite confusing. Unfortunately, if you have the option checked, the color selections are grayed out: giving you, in effect, no idea what “Windows Colors” will actually be. This may not be a problem in a default set up; but if you have changed your Windows Color, you may have no idea what to expect. When you uncheck the option, the color fields once again light up and give you your options to change.

Internet Explorer 6

Colors Options: Tools » Internet Options » General » Colors

Although fundamentally a very similar interface to the later versions, the color selection tools in IE 6 are, to me, much clearer than the later events. The grouping of features makes more sense, as does the indication of current defaults — which are at least available for link colors, if not for text and background colors.

One of the biggest problems, in my opinion, with the design of the Internet Explorer interfaces (all of them) is that rather than giving you the option to override web page settings at the same time you establish your settings, you have to create the settings and set the override selection in separate menus. In IE 7 and 8, adding insult to injury, the interface takes up space to link to instructions on how to ignore presets — space which could just as easily have been occupied by a checkbox to perform that action.

Custom Stylesheets

Most browsers allow you to attach your own custom style sheet. These style sheets use the Cascading Style Sheets format to allow you very fine control over how web sites you visit will display. They are, however, somewhat beyond the skill level of the average web user. Nonetheless, it’s valuable to know that the feature is available — if you are unable to enable your browser to provide what you need, you may be able to accomplish it with custom styles.

Opera Custom CSS: Tools » Quick Preferences » Edit Site Preferences » Display

The richest options available at this time are for the Opera browser. Opera allows customization on a site-specific level, allowing you to specify detailed characteristics for each site you visit.

Firefox Custom CSS: Complicated by hand, easy with plugins…

In it’s default installation, Firefox simply doesn’t offer a practical way to install custom styles. However, the easy extensability of Firefox through browser add-ons solves this problem readily. The most popular and easiest to use option is the Stylish add-on, which provides functionality to add custom styles at the site level or the global level. Additionally, Stylish maintains an online repository of user-created styles.

Safari Custom CSS: Edit » Preferences » Advanced

You’ve already seen this menu above, and it seems fairly straightforward. I will say, however, that I had a great deal of difficulty managing style sheets. The behavior of the interface was quite buggy. It’s difficult to describe, except to say that the differentiation between selecting to choose a style sheet and loading a new style sheet was extremely weak. It was not uncommon for them to behave in a different manner from what I expected. Altogether, at this time I’d say that the functionality is present, but at least in my installation, nearly unusable.

IE 6/7/8 Custom CSS: Tools » Internet Options » General » Accessibility

Unlike Opera by default and Firefox with the Stylish plugin, Internet Explorer offers only a single global custom stylesheet to be added. Nonetheless, there’s a lot you can do with global styles: and at least the interface works.

Conclusion

Most modern browsers provide the user with the ability to set their preferred default font size, text and background colors, and link colors and decoration. Some browser provide much richer features than that, allowing site-specific options and setting a minimum base font size to prevent microscopic text. In general, browser options tend to be richer and more reliable than the same functionality provided by any web-site based text widget; but may be significantly less apparent to the user.

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

Refining Text Presentation with your Web Browser: Windows

This is the message in its entirety:

Dude how come your example poll have this amazing format, cool graphics, and when I download and installed yours, looks like SHIT?

I mean, thanks for doing this and all that, but come on, you are showing a FALSE example on your web site.

The example poll referred to is this: an example installation of a free MySQL/PHP polling script available on my website. Now, I find it hard to believe that anybody actually thinks of that example as having “this amazing format, cool graphics,” but that’s not really the point: the question is what a “free script” should be expected to include.

This person obviously expected a fully-realized, designed installation. What I provided was nothing but raw HTML and PHP scripting. No “out of the box” styling at all. This is what I generally desire out of a script: if it has a few hooks for CSS and semantic code, that’s great!

I can certainly agree that if you want something you offer to really become a major player in the world of popular downloads, you’ll need to put in a fair amount of work in providing easy template styling, etc. But I hardly think that should be expected for a simple web site add-on.

It leaves me curious: when you download a script, what do you expect of it?

Articles from Accessible Web Design © 2008 Joseph C Dolson. This feed is for personal non-commercial use only.

What does a “free script” need to provide?