[Skip navigation links]

CompanyPowerMapper Software products are used in more than 50 countries by some of the world's largest organizations. Over 30% of the Fortune 100 use our products.

PowerMapper Software Blog

Covers product updates, company updates and useful information on accessibility, browser compatibility and search engine optimization / SEO.


Page Title Length for Search Engines

posted by Mark Rogers on Apr 14, 2013 | 

SEO

Ever been wondered why there's a lot of conflicting advice about longest page title allowed in search results pages (SERPS)?
 
The short answer is different search engines have different limits and these limits keep changing. The current official guidelines, as of April 2013, are:
  • W3C recommends a maximum of 64 characters for page titles.
  • Bing recommends a title around 65 characters long.
  • Yahoo recommends a maximum title length of 67 characters (although this advice is obsolete since Bing now supplies Yahoo's search results) 
  • Google don't have any guidance for content publishers, and now limits the title on the visible (typographic) width displayed in the browser. For example, both these titles are 41 characters long, but one is much wider when displayed in a browser:
    • WWW2012 - WORLD WIDE WEB CONFERENCE 2012
    • HTML 5 - proper use of the title element
 
To see how these play out, we searched for "patent 7143296" in the top three search engines:
  • Bing - some titles up to 71 characters are displayed in full, but titles with a large visible width (for examples, titles all in CAPS) are truncated at a much lower limit (around than 50 characters in some cases)
  • Google - some titles up to 71 characters are displayed in full, but titles with a large visible width (for examples, titles all in CAPS) are truncated at a much lower limit (around than 40 characters in some cases)
  • Yahoo - results are now provided by Bing (since mid-2010)
 
This table shows how the maximum title length in the major search engines has changed over time:
YearGoogleBingYahoo
2007 66 chars 65 chars 120 chars
2008 66 chars 65 chars 72 chars
2009 71 chars 65 chars 72 chars
2010 71 chars 67 chars 65 chars
2011 71 chars 70 chars Uses Bing results, so inherits Bing limits
2012 Visible width up to 70 chars 70 chars  
2013 Visible width up to 70 chars Visible width up to 71 chars  
These limits have changed over time, and are likely to keep on changing as the search engines store more pages and optimize retrieval speeds. It's worth noting that the data volumes to store page titles are not trivial. As of Apr 2010 Google had indexed 13 billion web pages, so that's 13 billion page titles to store, with multiple redundant copies needed to provide backup in the event of disk failure.
 

Most computers will open PDF documents automatically, but you may need to download Adobe Acrobat Reader.

Update: Orginally posted April 2010, updated April 2013



HTML 5.0 becomes W3 Candidate Recommendation

posted by Mark Rogers on Dec 18, 2012 | 

Web Standards

After 4 years of development HTML 5.0 finally exited draft status and became a W3 Candidate Recommendation on Dec 17, 2012. HTML 5 will now go through the final stages of the W3 standardization process before becoming a full Recommendation in 2014 (the final published standard). The only changes now to HTML 5.0 will be bug fixes, fixing typos and the possible removal of "at risk" features.

New features will be added to the HTML 5.1 draft specification, which is planned to become a Candidate Recommendation in 2014.

At Risk Features

Some features are deemed at risk features because they don't have two separate, fully working implementations. The list of at risk features includes:

  • <hgroup> and the HTML 5 heading outline algorithm 
  • <menu> and contextmenu attribute (context menus)
  • <dialog>
  • <details> and <summary>
  • <input type=color>
  • <input type=datetime>, <input type=month>, <input type=week>, <input type=time>, <input type=datetime-local>

In the event that browser vendors are unable to implement these features as specified, these are likely to be removed from the HTML 5.0 final recommendation.

HTML 5 Statistics

Graph: HTML versions in use in December 2012: HTML 5 accounts for over 30% of pages, XHTML 1.0 and 1.1 accounts for 46% of pages and HTML 4.01 for under 7% of pages

Our online service scans around 200,000 pages each month - these are often new sites in development. Around 30% of pages scanned  in December 2012 use the HTML 5 doctype, but of these only half (or 15% of the total scanned) use new HTML 5 elements and attributes (things like <footer> and <input required>). The XHTML 1.0 and 1.1 document types (the previous versions of HTML) accounts for just under 50% of pages scanned.

For comparison, the Blekko search engine has a much larger sample of 1 billion pages scanned in April 2011, showing the XHTML doctype used on ten times as many pages as the the HTML 5 doctype. The Blekko sample is likely to include more older pages than our online service.

Key Takeaways

HTML 5 use is increasing steadily and is likely to accelerate as it nears full recommendation status.

 

 


tags:

Comment »


SortSite 5 Now Available

posted by Mark Rogers on Dec 6, 2012 | 

SortSite Blog

SortSite 5 is now generally available with over 700 quality checkpoints. New features in version 5 include:

  • Record and replay form actions (Professional version only)
  • Enhanced browser compatibility checks allowing ability to choose which browsers to check
  • Analyze and check changes made to pages by JavaScript
  • ARIA support
  • HTML5 validation
  • Performance improvements - twice as fast scanning some sites

Record Form Actions

SortSite Professional allows you to record form actions and replay them during scans to check the results of the form action. For example you can record typing into a search box, then replay this to check the search results page.  

Browser Compatibility

The compatibility checks now let you specify which browsers to check, and have been updated to the latest browser versions including iOS6 and Internet Explorer 10.

JavaScript Changes

Changes made to the DOM by JavaScript can now be analyzed. For example, slideshows created by jQuery often have missing ALT text, and these can now be checked for accessibility problems. 

ARIA Support

ARIA roles and attributes are now validated using the HTML5 ARIA rules.

HTML5 Validation

The W3 version of HTML5 can now be validated. The HTML5 specification is still at working draft stage, and subject to change, but is expected to reach full recommendation status in 2014. A large number of new rules have been added to support HTML5 validation - see the list of changed rules in SortSite 5.0.

Performance Improvements

Scanning sites is now 2-3 times as fast as SortSite version 4. The performance gain is most noticeable on larger sites with lots of external links.

Other Changes

Other changes include improved rendering in the embedded browser, and reduced memory consumption. See the SortSite Version History for a full list of changes.

tags:

Comment »


Government Accessibility Standards and WCAG 2.0

posted by Mark Rogers on Nov 13, 2012 | 

Accessibility | Web Standards

This posting summarizes some detailed research into the state of government accessibility standards around the world, as of November 2012. Usually these evolve fairly slowly, although the recent Jodhan vs. Attorney General of Canada case may change that (governments don't like being successfully sued by their citizens).

In general, these standards apply to government agency websites (and not commercial web sites) with the exception of Australia where commercial sites are also required to comply. Other countries have disability discrimination laws which cover websites, but these don't specify the technical standards required to comply with the law.

This table shows government accessibility standards, and relevant legislation, in 17 territories:

CountryStandardLegislationApplies To
Australia WCAG 2 AA Disability Discrimination Act All government and non-government websites should comply with WCAG 2 AA by end of 2013
Canada

WCAG 2 AA

Human Rights Act 1977 Common Look and Feel 2.0 required WCAG 1 up till July 2011 for all government websites. The Jodhan vs. Attorney General of Canada ruling requires the Canadian government to update the guidelines to WCAG 2, and this was implemented as the Standard on Web Accessibility on Aug 1, 2011.
EU WCAG 1 AA European Parliament Resolution (2002) 0325* Required for all EU commission websites - see EUROPA - Web accessibility policy. Progress towards WCAG 2 is being done by the Mandate M 376 working group which started work in 2006.
France RGAA 2.2.1 (based on WCAG 2) Law No 2005-102, Article 47 Required for all French central government websites by May 2011. All other French public websites (public services, towns, public research, etc) are required to comply by May 2012.
Germany BITV 2 (based on WCAG 2) Federal Disabled Equalization Law (BGG) BITV 2 came into force on Sept 22, 2011, and is required for all government websites. It is based on WCAG 2, but not identical.
Hong Kong WCAG 2 AA   WCAG 2 AA became the standard for GovHK websites in March 2012.
India Guidelines for Indian Government Websites (based on WCAG 2 A)   WCAG 2 Level A became the standard for Indian government websites in February 2009.
Ireland WCAG 1 AA The Disability Act 2005 All government websites - Code of Practice on Accessibility of Public Services and Information Provided by Public Bodies 
Italy

Technical Rules of Law 4/2004 (based on WCAG 1 AA) 

Law No. 4/2004 (“Stanca” Law) Required for all government websites
Japan JIS X 8341 (based on WCAG 2)   Based on WCAG 2 with provisions made for the Japanese language and input systems. Required for all local and central government websites. Commercial websites are also encouraged to use it.
Netherlands WCAG 1 A   Government websites must comply with the government web guidelines, which include WCAG 1 A. There are no requirements for non-government websites.
New Zealand WCAG 2 AA Human Rights Amendment Act 2001 Web Accessibility Standard 1.0 (WCAG 2 AA with some exceptions) required for all government web sites.
Norway   LOV 2008-06-20 nr 42: Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne The law requires all websites to be be universally designed. There's an ongoing consultation on whether to apply a technical requirements of WCAG 2 at level AA (with the exception of 1.2.3, 1.2.4 and 1.2.5 which apply to timed media)
Ontario AODA (WCAG 2 AA)   Required for all new Ontario government websites by January 2012, and existing government websites by January 2016.
Quebec SGQRI 008 (based on WCAG 2) Standards sur l'accessibilité du Web Custom made standard based on WCAG 2.0 with specifics covering websites, downloadable documents and multimedia.
Spain  UNE 139803:2004 (based on WCAG 1 AA) Law 34/2002, Law 51/2003 Required for all government websites. No mandatory requirements on non-government websites.
United Kingdom WCAG 1 AA or
WCAG 2 AA
Equality Act 2010 The COI standard for inclusive websites requires WCAG 1 AA or WCAG 2 AA for all UK government web sites. Other UK websites need to comply with the Equality Act and provide equal access, but this doesn't specify technical standards (although complying with at least WCAG 1 A or 2 A demonstrates that accessibility issues have been considered).
USA Section 508 (subset of WCAG 1 with a few additions) Section 508 of Rehabilitation Act US federal agencies' websites must comply with Section 508 guidelines. These are currently being updated and will incorporate WCAG 2 AA - but the update has been subject to continual delays through 2013 and 2014.

* Irony Alert: the European resolution insists web site documents should be clear and simple, but kicks off with 22 paragraphs of incomprehensible bureaucratic text. Here's an example:

whereas the internet as a part of society is an instrument for society as a whole, so it is fundamental that technologically neutral access to public information is offered for all groups in society...

The key takeaway from this research: adoption of WCAG 2 is progressing steadily and becoming increasingly important:

  • The governments of Australia, Canada, France, Germany, Hong Kong, Japan and New Zealand have already adopted WCAG 2.
  • UK government sites must comply with either WCAG 1 AA or WCAG 2 AA.
  • In the US, Section 508 is being refreshed to harmonize with WCAG 2.
  • The European Commission is investigating a move to WCAG 2 as a European government standard, but this is complicated by competing national standards in Germany (BITV) and Italy. 

Edit: originally published November 2010, updated July 2014.



Accessibility, SEO and Social Media: How They Overlap

posted by Mark Rogers on Jul 20, 2012 | 

Accessibility | SEO

Search engines can't see and can't click, so there's a big overlap between making sites accessible and making sites perform well in search engines. Social media also uses several features that improve accessibility. 

This table shows the relationships between WCAG 2 Accessibility Checkpoints, search engine optimization and social media. The priority levels from WCAG have been used for SEO and social media: A is most important, AAA is least important. 
 

 AccessibilitySEOSocialWCAG 2 Checkpoint
Text Alternatives A A   1.1.1
Video Transcripts A A   1.2.1
CSS Content A A   1.3.1
Images of Text AA A   1.4.5
Page Titles A A A 2.4.2
Link Text A AA   2.4.4
Multiple Ways to Pages AA A   2.4.5
Headings and Labels AA AAA   2.4.6
Link Purpose AAA A   2.4.9
Section Headings AAA AAA   2.4.10
Language of Page A A   3.1.1
Parsing A AA AA 4.1.1
Meta Descriptions   A A  

Text Alternatives (ALT Text)

Search engines and blind people can't see images, so they need text alternatives to describe important images. 

<img src="red-sands-resort.jpg" alt="Red Sands Resort is perched on the slopes of Olympus Mons, overlooking the Tharsis plain, 200 million km from the nearest beach" /> 

How Search Engines use ALT Text

ALT text is used in image search, and also used as anchor text when a link surrounds the image. Anchor text helps to determine the topic of the target page, with offsite anchor text given more weight because it's harder to manufacture links on lots of different sites.

How Social Media uses ALT Text

Currently social media sites like Pinterest and Facebook don't capture ALT text when images are shared. Pinterest uses the image description typed when the user pins the image. Facebook sets empty ALT text for thumbnail images of shared pages - even if the shared page contains ALT text for the thumbnail image.

How Screen Readers use ALT Text

Screen readers read out ALT text in place of images. Images which are essential to understanding or functionality must have ALT text:

  • Images which are the only content of a link need ALT text 
    <a href="/"><img src="logo.png" alt="Home Page"></a>
  • Image form buttons need ALT text
    <input type="image" src="submit.png" alt="Book Mars Trip" />
  • Images containing essential information need ALT text
    <img src="radiation-hazard.png" alt="Danger - radiation hazard beyond airlock" />  
     
Some images (especially clip art and stock photos) are decorative and should be assigned empty ALT text, which avoids unnecessary noise from the screen reader:
  • Spacer images must have empty ALT text
    <img src="transparent-spacer.png" alt="" />  
  • Information free images (often stock photos) should also have empty ALT text
    <img src="images/stock-photos/grinning-businessmen-shaking-hands.png" alt="" />  

Warning: This is one place where SEO guidelines and accessibility guidelines part company. Both Google and Bing recommend all images should have ALT text (which makes them easier to index for image search) but this harms accessibility by adding noise to the page for purely decorative images.

Video Transcripts

Just like images, search engines and blind people can't see video, so need text alternatives. Sometimes optimizing a site for SEO has the side effect of producing very accessible content. A good example is SeoMoz (a producer of SEO tools) who add transcripts to all their videos to help with ranking. This has the side effect of making the video accessible to the deaf.

SeoMoz - Whiteboard Friday

CSS Content

The CSS content property allows text to be inserted dynamically - a typical usage is adding a page number to the footer of printed documents.

div.caption { content: "Red Sands Hotel"; } 

Text inserted using the CSS content property is invisible to a search engine. Some low vision and dyslexic users turn off stylesheets, or apply their own CSS stylesheet. This allows users to set combinations of text color, background color and font style that work best for their particular abilities. For these users content inserted via CSS is never displayed.

Images of Text 

Images of text cannot be seen by search engines or screen readers. It's nearly always better to use text styled with CSS. The main exceptions are:

  • Logos which may require very specific font styling not available using CSS (e.g. the Coca Cola logo)
  • Scans of historical documents such as the US Declaration of Independence (transcripts should be provided in this case)

Page Titles 

The title tag is crucial for SEO and social media, and very important for accessibility. Title tags identify a page to the user - they appear in lots of different places: search results; browser tab titles, bookmarks and Facebook shares.

<title>Magnificent vacations on Mars - Travel - Destination Travel</title> 

How Search Engines use Title Tags

Screenshot of title and meta description in Google search results

The title is the most important item on a page for a search engine, and should be written for users. A good rule of thumb is to write titles the same way as a quality newspaper writes headlines. An informative title like "Good title tags boost business results" gets clicked on a lot more often than a keyword stuffed title like "Good title tags, best title tags, cheap title tags, title tag advice".

Words at the start of the title are read more often during a quick scan of the results, so carry more ranking weight with the search engine. For this reason, don't put the site name at the start of page titles (other than on the home page).

Don't use the same title tag on every page on your site - because the title has a huge influence on ranking this greatly reduces the number of keywords your site will rank well for.

For more information see Title Tag Optimization for Usability and SEO

How Social Media uses Title Tags

Screenshot of title and meta description in Facebook share

Facebook and Digg show the page title for shared links, along with any meta description.

How Screen Readers use Title Tags

The title is the first thing read when a page loads, and is very important for letting the user know where they are. Having identical titles on every page is very confusing.

Link Text and Link Purpose (Anchor Text)

<a href="things-to-do.htm">Things to do on Mars</a>  

How Search Engines use Link Text

Search engines use the underlined link text (called anchor text in the SEO world) as a vote on the topic of the target page. If enough anchor text points at a particular page, searching for that anchor text returns the page even if the text doesn't exist on the target page. This has been exploited in the past by Google Bombing.

How Screen Readers use Link Text

Three main screen reader interactions use link text:

  • Tabbing through the links on a page (each time  the user presses the tab key the link text is read out)
  • Using the screen reader "List Links" command to read out the anchor text of all the links on the page
  • Sequential reading where the link is read as part of the surrounding text

In first two cases the links need to make sense out of context by clearly identifying link purpose. In particular, labeling all your links "Click Here" or "Read More" renders the links useless to screen reader users unless they read sequentially.

Multiple Ways

A single navigation mechanism (such as a navigation bar) may block or slow down some users with disabilities. Providing multiple navigation methods (navigation menus, search and a site map) helps disabled users avoid these blocks. 

How Screen Readers use Multiple Ways to Pages

Blind and low vision users may find it quicker to navigate using site search, or search for text in a site map, rather than tabbing through a navigation menus in set of linked pages.

How Search Engines use Multiple Ways to Pages

Search engines count internal and external links to a page to work out how important the page is. Providing multiple internal links to a page increases the chances that page will be indexed.

Headings H1-H6

<h1>Magnificent vacations on Mars</h1>  
<h2>Prices for vacations on Mars</h2>  
<h3>Budget Vacations</h2>  
<h3>Luxury Vacations</h2>  
<h2>Related: vacations on Venus</h2> 

How Search Engines use Headings

Headings help the search engine understand the topic of a page. The headings on this blog post help indicate the page is about screen readers, search engines and social media.

How Screen Readers use Headings

Many screen reader users read out a list of headings as soon as the arrive at a page to get a quick overview of a page - this is equivalent to a sighted user quickly scanning the page before deciding to hit the back button. They're also used to quickly navigate to the part of page the user is interested in. Without headings the user has to laboriously read the page from the top.

Language of Page

The HTML tag at the top of each page should identify the language the page is written in:

<html lang="en">

How Search Engines use Language

Search engines can guess the language of a pages, but sometimes guess wrongly (especially on multi-lingual sites). Without this attribute a French language page on a Canadian site may appear in English search results instead of French search results (or more likely not appear at all).

How Screen Readers use Language

This attribute is used when selecting a voice to read out the page in. Without this attribute a French language page can be pronounced like English in a screen reader (which is unintelligible to a French speaker).

Parsing

How Search Engines Parse Pages

Search engines parse pages using "tag soup" algorithms that are very forgiving of errors. Relying on this can cause problems, because error handling wasn't standardized until HTML5. This means an unclosed tag may be handled differently by different search engines. Particular problems include:

  • Missing comment end tags which can hide large portions of a page from a search engine. This is because the parser has to guess where the comment should end, and may choose the next line, or the end of the next comment, or the end of the page.
  • Unclosed <title> tags also cause problems because the parser has to guess where the title should end, and may drop the title from the index.
  • Missing closing quotes from meta descriptions attributes cause similar problems since the parser has to guess where the description ends.

How Social Media Parse Pages

Facebook and Digg displays page title and meta description when a link is shared, so Facebook needs to parse the page in the same way as a search engine to extract this information. The same problems with malformed tags apply.

How Screen Readers Parse Pages

Screen readers rely on the host browser parsing pages before interacting with the browser DOM via accessibility APIs. The way browsers handle malformed code sometimes changes between browser releases. There were parsing changes between Internet Explorer 7 and 8 as well as parsing changes between Firefox 3 and 4.

Meta Descriptions

Meta descriptions provide a short description of a page, and are displayed below page titles in search results and shared links in Facebook.

<meta name="description" content="With nearly every corner of Earth developed, more of today's elite tourists are boarding rocket ships to vacation in hundreds of off-planet hotels, resorts and spas that are putting a new spin on 'out-of-this-world' luxury" />

How Search Engines use Meta Descriptions

Screenshot of title and meta description in search results

The meta description usually appears below the title, with keywords from the user's search phrase in bold.

The description should give users a reason to click - a description that says "Under construction" is unlikely to get many clicks. Use language that people actually use in searches rather than corporate jargon, because this means more text is bolded to attract attention which increases the number of clicks.

How Social Media uses Meta Descriptions

Screenshot of title and meta description in Facebook share

Facebook and Digg show the page meta description just below the page title for shared links.

How Screen Readers use Meta Descriptions

Not used directly by screen readers, but will be read out as part of search results pages returned by Google and Bing. 

Conclusion

Optimizing a site for search engines and social media usually makes it more accessible. Making a site more accessible optimizes it for search engines and social media. Do both!


tags:

Comment »


Desktop Quarterly Releases - Feb 2012

posted by Mark Rogers on Mar 21, 2012 | 

PowerMapper Blog | SortSite Blog

The latest quarterly PowerMapper and SortSite maintenance releases are now available.

New features include:

  • View Source command added to right click menu
  • Updated W3 DTDs to match validator.w3.org (pulls in fix for usemap in XHTML 1.1 Second Edition)
  • Added compatibility checks for Firefox 9,10,11 and Chrome 16,17 versions
  • Added support for CSS3 properties that have reach candidate recommendation status

Fixes include:

  • Handle zero sized thumbnail images caused by buggy display driver
  • Avoid blank thumbnail images on pages that only contain Flash movies or META refresh directives
  • Don't detect broken anchors in non-standard CSS e.g. behavior:url(#default#savefavorite)
  • Various false positives
  • False negative: didn't detect empty headings
  • False negative: <A ONCLICK> with no HREF cannot be operated from keyboard

These are available to all customers with active support and maintenance contracts via the Update Watch feature in each application.


tags:

Comment »


W3 ARIA - why doesn't it validate?

posted by Mark Rogers on Mar 4, 2012 | 

Accessibility | SortSite Blog | Web Standards

The W3 ARIA recommendation specifies new HTML attributes (like "aria-describedby") to help screen readers identify relationships between elements. These new attributes tell screen readers about relationships that can't be derived from existing HTML semantics, and usually only obvious from the position of items on screen (e.g. a paragraph of help text next to a form field).

Most people who've tried adding ARIA attributes to HTML have noticed that documents don't validate unless the HTML 5 DOCTYPE is used: <!DOCTYPE html>.

Why is this - are the validators all broken? Unfortunately, the problem is worse than this.

What's the problem?

The validation rules used by validator.w3.org and the other validators out there (including SortSite) use a machine-readable description of HTML called a Document Type Definition (DTD). Prior to HTML 5, each version of HTML and XHTML was specified by a DTD describing which element and attribute names are allowed in a document.

Here's the problem:

  • The W3 specifications of HTML 4.01 (1999),  XHTML 1.0 (2000 revised 2002) and XHTML 1.1 (2001 revised 2010) all pre-date ARIA (2011) so weren't aware of ARIA at the time of writing.
  • The W3 specifications all contain DTDs that are marked as normative (i.e. the DTDs are a prescriptive part of the specification, so cannot be changed and aren't open to interpretation). 
  • This means that ARIA can't be added to these DTDs without revising the underlying specifications 

In retrospect, including DTDs as part of the normative specifications of HTML and XHTML was probably a mistake by the W3 working groups, and one that's been avoided in HTML 5 which doesn't use DTDs. HTML 5 also has the advantage that it's still draft, which allowed ARIA to be added relatively easily.

Don't expect the W3 to add ARIA to DTDs for old versions of HTML any time soon. Even fixing obvious bugs in the DTDs takes a very long time, because it requires a specification revision. The usemap bug in the XHTML 1.1 DTD took 8 years to fix - prior to the 2010 revision of XHTML 1.1 you had to choose between working image maps or valid code.

Does HTML 5 fix this?

Going the HTML 5 route isn't a panacea: the validation rules for HTML 5 never quite match the current HTML 5 draft specification because the draft is constantly changing, as do the HTML 5 validation rules. The HTML 5 validator is quite up front about this, when you validate HTML you see this message:

"The validator checked your document with an experimental feature: HTML5 Conformance Checker. This feature has been made available for your convenience, but be aware that it may be unreliable, or not perfectly up to date with the latest development of some cutting-edge technologies."

This situation is likely to continue until HTML 5 reaches Candidate Recommendation status - probably sometime in 2012/2013. 

What else can I do?

The ARIA working group are aware of the problem, and have produced two unofficial DTDs that do allow ARIA to validate:

XHTML 1.1 with ARIA
http://www.w3.org/TR/wai-aria/appendices#xhtml_dtd

HTML 4.01 with ARIA
http://www.w3.org/TR/wai-aria/appendices#html_dtd

These DTDs are both available in validator.w3.org and SortSite 4.6, but as the ARIA recommendation notes, using the DOCTYPEs for either of these DTDs cause significant problems in browsers (such as character entities like &NBSP; not working correctly).

In SortSite the other option is to to selectively ignore validation errors for aria- prefixed attributes using Ignore Rule menu command. To do this right click on the Rule Options link next to an error for an aria feature, and choose Ignore Rule.

Catch 22?

If you want to use ARIA and be standards compliant you're in Catch 22 situation:

  • Use the HTML 5 doctype (but be aware that what validates today may not validate tomorrow because the HTML 5 validator isn't stable yet)
  • Use ARIA in HTML 4.01 or XHTML 1.x and live with the validation errors and the fact you're no longer compliant with the XHTML and HTML 4 specifications (plus you risk missing real validation errors  in a sea of ARIA validation errors)
  • Use a validation tool that lets you disable ARIA specific validation errors

tags:

Comment »


How disabilities affect website use

posted by Mark Rogers on Feb 4, 2012 | 

Accessibility | Web Standards

This post  follows on from the one on Disability Statistics, and shows how the most common disabilities affect website use.

Reading Difficulties

Reading difficulties and dyslexia are extremely common, and affect 15-20% of US adults. Some groups (such as entrepreneurs) have rates approaching 40%.

This group often finds problems with:

  • Large blocks of text
  • Very high contrast text*, such as black text on pure white affects people with Scoptic Sensitivity Syndrome (which makes the letters dance about)
  • Fully justified text aligned to both left and right margins (contains rivers of whitespace which break up the text)
  • Flashing or moving elements, which attract the eye and make it hard to concentrate on reading text  

* Note that the high contrast required by WCAG 2 checkpoint 1.4.3 can actually cause problems for people with Scoptic Sensitivity Syndrome, and also some low vision users who need to read the screen very close up (put your face next to your screen for 30 minutes on a very high contrast page to see how unpleasant this feels). 

Color Blindness

Color blindness is also very common, and affects around 8% of caucasian males in the US, but only 0.5% of females. Color blindness comes in many varieties with red-green and blue-yellow color blindness the most common, and inability to see any colors (monochromacy) the rarest.

This group often finds problems with:

  • Text and background colors with little difference in brightness 
  • Red text on a green background, or green text on a red background (looks like brown text on a brown background to someone with red-green color blindness)
  • Blue text on a yellow background or yellow text on a blue background  

Dexterity Difficulties

Problems using hands and arms affects around 7% of the population, and can make using a mouse hard or impossible. Older people are more likely to have dexterity problems due to the onset of arthritis. Even if users can use a mouse, they'll find it hard to click on small link targets (such as single character links).

This group often finds problems with:

  • Pages that can only be operated with a mouse (e.g. many street mapping websites)
  • Very small links that need very precise motor control to click (e.g. the single character links often used for paging)    

Difficulty Hearing

This affects around 4-5% of the population, and becomes more common with age. Relatively few websites use audio, so the majority of sites are unaffected. Many office workers are in the same position, since they have no way of hearing website content at work (speakers are very uncommon in offices, and headphones are frowned upon in some corporate settings). 

This group often finds problems with:

  • Videos where the audio track is needed to understand the content (e.g. a recording of a TV news bulletin) 
  • Standalone audio (e.g. a radio play)   

Difficulty Seeing

This affects around 3-4% of the population and includes people who are blind and those with low vision who need large print and/or high contrast to read (e.g. people with cataracts or retinal damage caused by diabetes). 

Blind people (and some dyslexics) typically use a screen reader, which read out the words on web page, but reading each word out individually is very time consuming so:

  • They use the <title> tag to find out what a page is about before going to the effort of reading it (so the same title on every page is not useful)
  • They often read out all the headings and link text first to figure out what a page is about (screen readers have shortcut keys for this)
  • The use headings inside the page to navigate to the section they're interested in (so pages without headings are hard to use)
  • They need a quick way to skip navigation links at the top of the page (you don't want to have to listen to 100 navigation links before hearing the page content)  

People with low vision:

  • Often use browser zoom feature to enlarge all the content (normal text enlarges well, but text inside graphics becomes pixelated)
  • May use a custom CSS stylesheet to enlarge text and provide color combinations that work for them (e.g. 24 point yellow text on a black background). This poses difficulties if your pages are unreadable without your site's CSS stylesheet.

 


tags:

Comment »


Picking Christmas Cards for People with Limited Vision

posted by Pam Nairn on Dec 13, 2011 | 

Accessibility

Well, it’s that time of year again. While I consider myself one of life’s formidably organised Christmas present buyers (I started in August) I seem to fall sadly short when it comes to finding the time to write and post my Christmas cards.

I know that to many, card writing seems an outmoded way of sending Christmas greetings, but for many of my ageing relatives, some of whom now live alone, a hand written card arriving in the mail is still much appreciated. Besides, I still enjoy choosing the cards - I fancy I always find something pretty tasteful!

Recently, a close friend paid me a compliment which really cheered me. Her mother has very limited vision - she's been registered blind for as long as I’ve known her. When choosing her card, I’ve always made certain that the design is simple, bold and very colourful. To me that just makes common sense. Surprisingly, few others do, and my friend tells me that her mother always enjoys my card arriving in the mail - it’s one of the few she can see. 

Since accessibility plays a large part in what we do here, I was pleased to know that I was practicing what we preached. 

 

tags:

Comment »


Having something important to say always beats slick presentation

posted by Mark Rogers on Oct 29, 2011 | 

Accessibility

Today is World Stroke Day, which aims to raise awareness of the condition. Earlier this week I saw a conference keynote speech by Clayton Christensen, author of The Innovators Dilemma and a Professor at Harvard Business School.

He introduced himself by apologizing for hesitating while speaking because he'd suffered a stroke a few months earlier. In spite of this he was an engaging speaker - much better than the other professional conference speakers. His points came across so well because he's been thinking about them for decades and backed them up with well-researched evidence. His only concession was asking the audience to interject when he couldn't remember a word, but this made the presentation more interactive and memorable.

At the end of the day having something important to say always beats slick presentation.


tags:

Comment »



Free Online Trial

Test a Website

Test websites for accessibility, broken links, browser compatibility, SEO and over 450 quality issues.

Build a Site Map

Site mapping tool for generating visual site maps and XML sitemaps.