Blog » Archive by category 'Accessibility'
Perfecting a web site is a long and involved process. There’s no getting around the fact that if you want every aspect of your site to be right — - accessibility, search optimization, and just all-around pizzazz, you’ve probably got some significant work to do. However, that’s not to say that there aren’t things you can check quickly and efficiently to make sure you’re not making some of the more egregious errors!
Here are 8 speedy checkups (in no particular order) which you can easily perform on your site to inspect it for problems. No methods suggested require special knowledge of HTML or web programming. Excluding acquiring and installing software, these tasks shouldn’t take more than a few minutes for most sites.
That doesn’t include fixing any problems found, of course…
Read more: Web site Tune-up: 8 Quick Checkups
There are a lot of services in the web marketplace offering code conversion. You give ‘em a design, they spew out some junk code for you. This isn’t the way it has to be, thankfully.
There are, believe it or not, PSD to HTML conversion services which are committed to creating standards compliant, semantic code.
Well, there’s at least one — http://w3-markup.com/. I’m not personally aware of others…
But the point is that if you’re a designer who needs a completed design transformed into semantic code, you don’t actually need to do it yourself. Or, alternatively, if you’re fully competent to do it yourself but short on time, you can speed things up using this service.
Advantages of the service:
- highly customized order process — the order form allows you to select numerous detailed customizations.
- their process allows you to work with their staff via live chat, conceptshare.com, and our client area intranet.
- guaranteed turnaround time.
Truthfully, the order form is pretty savvy in terms of providing you with ways to specify significant detail on exactly how your site is built. If you simply prefer that they use the Dojo Javascript library instead of Prototype — - that’s an option. The options are extensive.
Among the options, for example, are these options:
Web Content Accessibility Guidelines
A set of guidelines provided by the World Wide Web Consortium, these overlap with our own mobile and screen reader compatibility options however ours are more practical and up-to-date. If a specific version of the guidelines is to be followed please specify it in the comments section.
[…]
W3C Compliance
Currently 2.1 of the cascading style sheet standard is the most widely supported and capable version. Select 1 or 2 only if you have specific needs that require those versions. Select 3.0 if you wish us to use experimental or loosely supported techniques.
It seems to me that one of the key advantages to this service is the ability to work directly with their staff during the construction process. However, even without that, you can provide an incredible amount of detail concerning the development in the advance specifications.
If you have specific needs (such as accessibility beyond the guidelines), you’ll have the opportunity to discuss those issues with the developer while they work.
Oh…and I really like their tagline: “code is art….” I can appreciate that sentiment!
Disclosure: This is a paid review. But don’t worry — it’s honest.
Some time ago, while pondering whether web accessibility posed limitations on design, the thought occurred to me that there are presumably some colors which simply cannot be used for text or text backgrounds in any site.
WCAG 1 does not, in fact, provide any specific guidelines concerning color contrast. The formulas commonly used to judge this were specified in Techniques For Accessibility Evaluation And Repair Tools, published in 2000. The document is intended to help authors conform to WCAG, but is not actually part of the WCAG document.
The nature of the Web Content Accessibility Guidelines (WCAG) specifications of color contrast fairly well ensures that some colors in the middle range of the spectrum (in hexadecimal, generally between #666666 and #999999) simply won’t be compatible with any other color.
My first thought on this point was to create a chart of colors which simply couldn’t be used in these contexts. I decided against this, on the grounds that it didn’t really seem all that valuable to me. But the thought of viewing color contrast problems in a different way than most color contrast checkers stuck with me.
It seems that most color contrast checking tools work in one of two ways: they either take a webpage and check the contrast factors between text and background on that page, or they allow you to enter a pair of colors and find out how they mesh up. Since this article was authored, I’ve created this basic tool as well. Evaluate contrast between two colors.
What I’ve done instead is set up a color contrast checker which only requires you to enter one color, then displays a selection of possible color combinations using that color. It’s pretty straightforward: you can choose to view results ordered according to WCAG 1’s color brightness and color difference tests or according to WCAG 2’s contrast ratio algorithm. Either way, all three factors are displayed, providing a good sense for how the two systems differ.
The results can be quite interesting. Compare the results for #888888 under WCAG 1 and under WCAG 2, for example:
Altogether, I’m hoping that this tool provides an interesting way to approach color contrast issues and to view the differences between WCAG versions 1 and 2.
Resources:
Color Comparison Formulas
Color brightness formula: (must be greater than 125)
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Color difference formula: (must be greater than 500)
(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))
Contrast Ratio with Relative Luminance formulas: (greater than 3:1 for print sizes over 14pt Bold equivalence or 18pt normal, greater than 5:1 for smaller text)
(L1 + 0.05) / (L2 + 0.05) where L1 = 0.2126 * R1 + 0.7152 * G1 + 0.0722 * B1 on the RGB values of the lighter color and L2 = 0.2126 * R2 + 0.7152 * G2 + 0.0722 * B2 on the RGB values of the darker color.
Thanks to an off-hand comment from Steve Green while discussing a forthcoming Accessites article, I’ve spent some time today thinking about what it takes to write for accessibility.
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.
“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.
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+3), 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.
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
appletcenterfontdirisindexmenusstrikeu
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.
This is just cool:
“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:
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.
Return to Top
