CSE HTML Validator

CSE HTML Validator Std/Pro v10 generates a random accessibility tip message (unless disabled) to help developers create more accessible websites. I thought it would be helpful to display these accessibility tips here for everyone to see and for possible discussion and improvement.

What is Accessibility?

When a web site is accessible, it means that anyone, regardless of ability, can enjoy and use the web site effectively. As an added bonus, it also makes the web site more machine readable, and that often has search engine benefits.

As an example, image a web site with many images on it (using the "img" element). A blind visitor may be using a screen reader or talking browser to "view" this page. One of the most significant (and very easy to do) actions a web developer can do to increase accessibility and make a web page accessible is to supply appropriate "alt" text for each image. This "alt" text is what the user's screen reader or talking browser will read to the blind user because he/she cannot see the images. If this "alt" text is not there, then the web page often becomes inaccessible to blind users.

As an example, consider an image on a product page that says "Order Now" but there is no "alt" text for this image. Because there is no "alt" text, a blind user could easily get lost if they are trying to order the product. Instead, the image should have an "alt" attribute that is simply alt="Order Now". This will let a screen reader or talking browser tell the blind user that the image is the order button, and the user will then know what to do to continue ordering the product. Without this simple addition, a blind user would not be able to use the web page as effectively as a user who is not disabled.


Accessibility Tips in v10 (not in any order)

* Use the "tabindex" attribute to provide a logical tab order, BUT ONLY WHEN the default tab order is insufficient. AND BE CAREFUL! It is easy to introduce usability bugs when setting the order explicitly. "Tabindex" values can be from 0 to 32767 and do not have to be sequential or unique. When the same value is used more than once, the order is determined by which appears first in the character stream. Visit http://www.w3.org/TR/WCAG20-TECHS/H4 for more information.

* If needed or desired, use a style switcher to provide a conforming alternate version of a page. For example, use client-side JavaScript or a server-side scripting language like PHP or JSP to switch between external CSS files.

* Provide expansion or definition for abbreviations using the "abbr" or "acronym" element ("abbr" is recommended for better future compatibility). Example: <abbr title="World Wide Web">WWW</abbr>.

* Use the "title" attribute with "a" elements to further describe or clarify the purpose of the link and/or to provide mouse-over tooltips. Tooltips build user trust by telling visitors where links will take them. However, important information that the user should know before selecting the link, like warnings, should be described in the link text, and if a link will open in a new window or tab, a visual indicator of this should be provided.

* Although still allowed (not prohibited) by WCAG 2.0, layout tables should be avoided whenever possible in favor of CSS layouts in order to maintain the semantic meaning of table elements and the separation of presentation from content.

* Use the "caption" element with data (non-layout) tables to identify the table. Use the "summary" attribute for the "table" element to provide an overview of the purpose of the table or to explain how to navigate the table. The caption and summary text should not duplicate each other.

* Use the heading elements ("h1" to "h6") to identify headings. Do not use headings to simply change the appearance of text. Proper use of heading elements allows assistive technology and user agents to properly recognize heading text.

* Use the "ol" element for ordered lists, the "ul" element for unordered lists, and the "dl" element for definition lists. This makes it easier for assistive technology to navigate from list to list or from item to item.

* Use semantic markup elements like "em", "strong", "cite", "blockquote", "q", "quote", "sub", and "sup" when appropriate. Use "em" and "strong" to indicate structural emphasis, use "blockquote" for long quotations which may require paragraph breaks, use "q" for short inline quotations, and use "sub" and "sup" for subscripts and superscripts.

* Use the "table" element and other table elements ("tr", "th", "td", etc.) to present tabular information. This preserves data relationships even when users cannot see the table or the presentation format is changed. Do not use tabs or spacing to create visual presentations of columns.

* Use "dfn" to mark the use of a word or phrase where it is defined (the term, not the definition).

* Consider using the "link" element with the "rel" attribute to provide metadata about the position of web pages that are part of collection. For example, specify the URLs to the next, previous, and content pages. Consider also linking to a glossary page if appropriate.

* Use the heading elements ("h1" to "h6") to begin each section of content. This assists user agents and assistive technology in letting users navigate based on headings. Avoid skipping heading levels. Use CSS to change heading appearance.

* Provide a semantic grouping for related form controls using the "fieldset" and "legend" elements. This is most important for related radio buttons and checkboxes. If desired, CSS can be used to change the visual effect of using the elements.

* Use this technique to identify the purpose of a link using link text combined with its enclosing list item: http://www.w3.org/TR/WCAG20-TECHS/H77, or combined with its enclosing paragraph: http://www.w3.org/TR/WCAG20-TECHS/H78, or combined with its enclosing table cell and associated table headings: http://www.w3.org/TR/WCAG20-TECHS/H79, or combined with the preceding heading element: http://www.w3.org/TR/WCAG20-TECHS/H80, or combined with the parent list item: http://www.w3.org/TR/WCAG20-TECHS/H81. Note: Whenever possible, provide link text that does not need additional context.

* In "select" elements, use "optgroup" to group related "option" elements. Label the option groups with the "label" attribute. Avoid using dummy list entries to delimit groups.

* Provide text alternatives for ASCII art, emoticons and leetspeak.

* Avoid situations where horizontal scrolling may occur. This can cause trouble, especially for people with cognitive disabilities and low vision. To test, open pages containing text in a browser and resize the browser to 1/4 of the screen width to check for horizontal scrolling.

* Use the latest mature HTML and XHTML specifications (currently HTML 4.01 and XHTML 1.0). Avoid proprietary elements and attributes and avoid using features in a manner that is not supported by the specification.

* For required form controls, indicate the required status in the control's "label" or "legend". If not indicated by text (like "(required)"), then make sure the meaning of the indicator is explained before it is used. NOTE: Abbreviating "required" to "req." may be confusing.

* When style information is removed from a web document or styles are turned off, make sure that the meaning of content and structural relations are preserved.

* Use the CSS "letter-spacing" property to control the amount of whitespace between characters. Do not use blank characters (like space characters) that may change the meaning and pronunciation of words.

* Use CSS to include decorative images wherever possible. The CSS "background", "background-image", "content", and "list-style-image" properties can be used. This avoids additional markup in the content.

* When sizing fonts, use CSS and specify relative sizes using "em", percentages or named font sizes like "xx-small", "x-small", "small", "medium", "large", "x-large", "xx-large", "smaller", or "larger".

* Use CSS margin, padding, and positioning properties instead of spacer images.

* Limit line lengths to 80 characters or less. This makes reading easier, especially for those with certain disabilities. One way to do this is to use "div" elements with "max-width: 80em".

* Use CSS to control the visual representation of text. There are many CSS font, color, transform, and spacing properties to let you do this. Using CSS increases accessibility by separating structure from presentation. Also, avoid images of text.

* For better accessibility, consider using CSS to specify text and background colors of secondary content (such as banners, features and navigation) but avoid specifying text and background colors for the main content. This makes it easier for users to choose their own colors.

* Use percentages or "em" values in CSS for text container sizes. This helps eliminate horizontal scrolling (when using percentages) and text cropping (when using "em") when users increase the text size.

* For better accessibility, consider using CSS to specify borders and layout to delineate areas of a web page but avoid specifying text and text-background colors. This makes it easier for users to choose their own colors.

* For better accessibility, make sure that the order of content in the source code matches the visual presentation order. This makes it easier to access the content in the proper order.

* When using accesskeys with the "accesskey" attribute, use standard accesskeys if possible. An accesskeys standard is emerging from the UK government recommendation: 'S' - Skip navigation, '1' - Home page, '2' - What's new, '3' - Site map, '4' - Search, '5' - Frequently Asked Questions (FAQ), '6' - Help, '7' - Complaints procedure, '8' - Terms and conditions, '9' - Feedback form, '0' - Access key details. If using accesskeys, then consider using this standard (or another appropriate standard). Also, be aware that using accesskeys often reduces accessibility due to the problems it can create.

* When using "accesskeys", understand the benefits as well as the associated problems. For example, accesskeys can override pre-existing keyboard shortcuts in user agents or assistive technologies. Because of poor design and implementation, accesskeys can actually reduce accessibility in many cases.

Whew that's a lot to read.

Great idea to post this.

From my quick read.

The accesskey standards are important, thanks for that. Makes it much more likely that these will be used.

On the don't use use tables advice. The always use CSS camp tend to overstate their point implying, and sometimes arrogantly demanding, that CSS be used for everything. It doesn't take long for a developer to figure that the fully Stalinist version of this advice is plain wrong. That balance should be prominent in any version of use CSS advice.

MikeGale wrote:On the don't use use tables advice. The always use CSS camp tend to overstate their point implying, and sometimes arrogantly demanding, that CSS be used for everything. It doesn't take long for a developer to figure that the fully Stalinist version of this advice is plain wrong. That balance should be prominent in any version of use CSS advice.

Yes, I agree... "always" advice is very strong and is often wrong... there are usually exceptions. I do think, however, that, when possible, it is best to use CSS for layout instead of tables... but I'm sure that tables are better in some situations.

Totally agree that where CSS fits it's the way to go.

However. I remember wasting a lot of time years ago when I tried to use CSS to do a job. I unfortunately drank the Kool Aid served up very widely at the time.

At the end of the day no sensible design, for the job I was doing, was possible with CSS. I guess a lot of web authors have been through this nonsense. I presume at least man centuries of time have been blown by the overhype.

That's not to say that there isn't a way of doing it well with CSS. The standards process is probably getting in the way of that by now so don't hold your breath!

(In fact if you look at the examples used to sell CSS, you can sometimes see how they've shaped the design to the technology, not to what they want to do!)

Hi Folks,

Albert wrote:* Use the "tabindex" attribute to provide a logical tab order when the default tab order is insufficient, but be careful when setting the order explicitly because it is easy to introduce usability bugs. "Tabindex" values can be from 0 to 32767 and do not have to be sequential or unique. When the same value is used more than once, the order is determined by which appears first in the character stream.

* Use standard accesskeys with the "accesskey" attribute if possible. An accesskeys standard is emerging from the UK government recommendation: 'S' - Skip navigation, '1' - Home page, '2' - What's new, '3' - Site map, '4' - Search, '5' - Frequently Asked Questions (FAQ), '6' - Help, '7' - Complaints procedure, '8' - Terms and conditions, '9' - Feedback form, '0' - Access key details. It is recommended that these accesskeys be used based on these recommendations.

I'm a tad surprised that these two come top of the list!

Not only are they the basis of putting intending designers right off
accessibility, because of their complexity, they are no longer part of
the specification. The world has moved on, and these two accessibility
features are not part of the webmaster's brief - they belong to the
browser designers, and always did!

As someone with disabled hands, I've researched this topic over a few
years, and adding these features, especially the accesskeys, can wildly
interfere with browsers with good accessibility built in - like Opera.
You'll turn it into a complete nightmare to use if you include them.

Don't assume that everyone uses IE - the bush-telegraph works just as
well for us and word soon spreads when a good (free) browser answers
our desire for ease of use. Because there isn't a mass market, or
perhaps because it's still not perceived as such, most of the assistive
technologies are prohibitively expensive, so free is always attractive.

There are other benefits to adding accessibility features, the link rel=""
especially can have major benefits in helping web robots to build a
much better overview of your site. Since I took the plunge, I've been
rewarded with at least a 20% increase in visibility, especially with
Google. Link rel="" is no longer limited to only assistive technologies,
it's built into Opera and you can have it enabled in Firefox via an
add-on too.

The approach I'd recommend is to take one step at a time. Start with
ordinary links and standardise them across your site. Take an "editor's"
approach. Add the title text and an indicator of some sort if the link is
to a page that will open a new tab or window. Avoid new windows for
pages on your own site. As for outside links opening a new window or
tab, well, there's currently a difference of opinion.

Then tackle the images - note that you use title text for images that
are without captions with alt="" (that's a blank alt text, don't repeat
the title text into the alt text), and alt text with the title text omitted
for those that are captioned (i.e. don't use title=""). For images that
are purely decorative and can't be included within your CSS, use the
blank alt text attribute.

Don't be caught out by the IE display of alt text, that's their quirk and
it's not standards compliant. The title text will work in IE just as well
as alt text does.

Then go for the link rel="" tags, the basic ones can be added to all
pages through a PHP include. From there it gets a tad complex, but
if you take it steady, it can be done. Just test it to destruction.
It took me about 3 months to individually add the unique links, like
previous and next, to over 800 pages. I noticed a difference in
visitor numbers before I had finished the exercise.

Whatever you do, don't be put off by accessibility, you'll not only get
some positive feedback, it's very personally satisfying too. Read
accessibility as enhanced usability for each and every one of your
visitors, include robots here and the benefits are mutually huge!

Did you notice that I followed the 80 character width limit advice?
My rule of thumb with this is "around 12 to 15 words per line".

Lowiepete wrote:I'm a tad surprised that these two come top of the list!

It wasn't in any particular order.

Lowiepete wrote:Not only are they the basis of putting intending designers right off
accessibility, because of their complexity, they are no longer part of
the specification. The world has moved on, and these two accessibility
features are not part of the webmaster's brief - they belong to the
browser designers, and always did!

I'm not sure what you mean by no longer part of the specification? The "tabindex" and "accesskey" attributes are still in HTML5.

However, I think that the idea that a developer could make things worse by using those attributes is definitely a concern and I will see if I can note that or reword the messages to warn about that.

Lowiepete wrote:There are other benefits to adding accessibility features, the link rel=""
especially can have major benefits in helping web robots to build a
much better overview of your site. Since I took the plunge, I've been
rewarded with at least a 20% increase in visibility, especially with
Google. Link rel="" is no longer limited to only assistive technologies,
it's built into Opera and you can have it enabled in Firefox via an
add-on too.

Interesting. I may incorporate that info into the tip, as well as use some of your other comments/thoughts to improve various messages.

Thanks!

Lowiepete wrote:Not only are they the basis of putting intending designers right off
accessibility, because of their complexity, they are no longer part of the specification.

Let me clarify... Although these attributes are still within the HTML specs,
their use has been more or less dropped from the accessibility guidelines.
Accesskeys in particular are an absolute nightmare from almost every
perspective.

This is the telling paragraph...

Albert Wiersch wrote:* When using "accesskeys", understand the benefits as well as the associated problems. For example, accesskeys can override pre-existing keyboard shortcuts in user agents or assistive technologies. Because of poor design and implementation, accesskeys can actually reduce accessibility in many cases.

I'd reword that as "accesskeys really do reduce accessibility!" I'm unsure why
it's us who get the blame for poor design. Accessibility, at that level, should
always have been kept as part of browser design. I guess that development
of M$IE, or lack of it in the past, was the cause.

Can I suggest that you move the relevant paragraphs so that they sit together
at the bottom - all the information in between is far more useful, especially
about lists, headings use and accessible forms. Adopting these has a real
side-benefit, it makes reading your HTML much easier while you write it,
because of its ordered structure.

Lowiepete wrote:Let me clarify... Although these attributes are still within the HTML specs,
their use has been more or less dropped from the accessibility guidelines.
Accesskeys in particular are an absolute nightmare from almost every
perspective.

OK, thanks. I understand what you're saying.

Lowiepete wrote:Can I suggest that you move the relevant paragraphs so that they sit together
at the bottom - all the information in between is far more useful, especially
about lists, headings use and accessible forms. Adopting these has a real
side-benefit, it makes reading your HTML much easier while you write it,
because of its ordered structure.

I moved the "accesskey" messages to the bottom. Thanks for the suggestion!

MikeGale wrote:(In fact if you look at the examples used to sell CSS, you can sometimes see how they've shaped the design to the technology, not to what they want to do!)

I'd agree with this to a point... however, the biggest limiting factor has nearly
always been "CSS hacks for IE". Floats and italics immediately come to mind.
I've avoided hacks like the plague, IMO just a way of storing up trouble, and
loads of work, for the future.

The patchy introduction of CSS3 across browsers, some of which I'd love to use,
is another reason for design limits. Attempting to design for any kind of site
longevity seems pointless. However, the redeeming aspect of that is the total
absence of complete site re-writes on a regular basis, just to keep up.

Separating content from its presentation does make life so much simpler and
makes the design tasks so much more satisfying. I certainly don't miss trying to
find my place in my previously convoluted table layouts, or the limitations
imposed upon getting things to fit.

Hello Albert,

Albert Wiersch wrote:What is Accessibility?

When a web site is accessible, it means that disabled users can use the web site as effectively as users who are not disabled.

Perhaps this could be reworded to take the sting out of the dreaded A word.
How about...
When a Web site is accessible, it means that anyone, regardless of their
ability, can visit your site and fully enjoy it without difficulty. It will also
provide valuable spider food by making your site far more readable by a
machine, with obvious benefits to you as the designer.

Can I suggest a small expansion to this...?

Albert Wiersch wrote:* Use the "title" attribute with "a" elements to further describe or clarify the purpose of the link and/or to provide mouse-over tool tips. However, important information that the user should know before selecting the link, like warnings, should be described in the link text.

The tooltips help build trust with your visitors by giving them a clear indication
of where the link will actually take them. This also applies to Web robots!
Where a link will open a new browser window or tab, a visual indicator of this
should also be added. A good example of its use is in Wikipedia.

In a previous post, I mentioned that there is divided opinion upon the use of
new windows, and it's quite polarised. However, where there is agreement
is with this visual indicator.

These two could be brought together...

Albert Wiersch wrote:* Use the heading elements ("h1" to "h6") to identify headings. Do not use headings to simply change the appearance of text. Proper use of heading elements allows assistive technology and user agents to properly recognize heading text.

* Use the heading elements ("h1" to "h6") to begin each section of content. This assists user agents and assistive technology in letting users navigate based on headings. Avoid skipping heading levels. Use CSS to change heading appearance.

However, there is a problem. The best way of describing this is to take a
newspaper as an example. h1 will obviously be the banner, then h2 will be
the main headline, h3 will be a secondary headline, h4 a section heading,
h5 and h6 sub-section headings and call-outs. All these are based upon a
"weight" of importance.

Where the problem occurs is that there isn't necessarily an h2 or h3 on every
newspaper page, and it's also unlikely on every web page either. Yet, the
standard insists that no heading step is omitted. Unlike the newspaper,
we will still need h1 on every page. What to do?

Well, for accessibility, you can still use all the headings, as very useful and
highly descriptive text, but in your regular CSS you can hide it, thus...

Code: Select all

HTML...
   <h1>RMS Caronia Timeline</h1>
   <h2>&ldquo;Welcome Home&rdquo;</h2>
   <h3 class="brk">The Cunard White Star Line's &lsquo;Green Goddess&rsquo;</h3>
   <h4 class="brk">Luxurious ocean travel aboard a world-famous British cruise liner</h4>
CSS...
.brk { display: none; font-size: 0.1em; line-height: 0.1em; margin: 0; padding: 0; }

The .brk class is then omitted from the style-switched CSS written for text only browsers.
Beware, make sure you don't use display: hidden; because you'll likely be penalised by
many Web robots, which will suspect underhand practices. Yet, you are providing good food
for them, and not having to write any separate HTML pages specifically for text browsing.

What this also means is that all instances of your headings stay consistent in their context
(weight?) across every page of your site. That's what I believe the purpose of this standard
is. Certainly, for keyboard tabbing purposes, it's essential!

Albert Wiersch wrote:* Provide a semantic grouping for related form controls using the "fieldset" and "legend" elements. This is most important for related radio buttons and checkboxes. If desired, CSS can be used to change the visual effect of using the elements.

These elements are not limited to forms! They can also be used to group sets of links into
separately headed categories, where use of h1 to h6 headings is not necessarily appropriate
or might confuse a visitor if overused.

Thanks Lowiepete,

I have incorporated some of your suggestions.

I kept the heading tips differently, because they refer to different WCAG techniques.

As for display: hidden, I assume you mean display: none. With regards to the search engine issue, do you have any reputable information on this? I could possibly provide an SEO message when this is used, but from my brief research, it seems that there are many legitimate uses for display: none so I think it's unlikely that search engines would penalize a site for using it, unless the engine/robot is somehow able to determine that it is being used for spamming and not for a legit purpose.

Albert Wiersch wrote:As for display: hidden, I assume you mean display: none. With regards to the search engine issue, do you have any reputable information on this?

For this purpose you must use display: none _not_ display: hidden!
They have different puposes in CSS, despite their similarity in labelling.
Use of display: hidden does risk getting penalised when attached
to text.

Indeed, for my index page, I have both the graphical and text-only HTML
within the same page - the text version giving a synopsis of the site using
this method. It's an attempt to replace a picture with less than a 1,000 words,
that also provides rich spider food. It's been in place for well over 2 years,
without any penalty that I'm aware of. A Google search for RMS Caronia
will bring the site up right at the top, pointing to that page. Right-click
and view source.

Although it's more in the domain of W3C standards, it's may be worth
reminding people that links should have a clear indication of visited /
yet to view status, and that the hover status should also be indicated by
more than just a colour change. It's surprising how many sites don't offer
this very basic functionality, yet it enhances both accessibility and
usability no end!

Lowiepete wrote:For this purpose you must use display: none _not_ display: hidden
They have different puposes in CSS, despite their similarity in labelling.
Use of display: hidden does risk getting penalised when attached
to text.

What purpose does display: hidden have? It is invalid CSS.

Oh... I bet you meant visibility: hidden. I will do further research into this and see if there is any agreement that visibility: hidden may be bad for SEO, and if so, may be worth noting this in the SEO messages.

Albert Wiersch wrote:Oh... I bet you meant visibility: hidden.

Yeah - it's these sleepless nights...