Accessibility and JavaScript Mouse Events

One of the most annoying things as a fellow developer trying to get his sites to pass accessibility checks is the "Make sure event handlers do not require use of a mouse" pass - which seems like an unavoidable scenario… I.e. you want something to happen when the user clicks the mouse… Nothing unreasonable there? Except when the user doesn’t have a mouse that is!

So we need a solution for those users too...

<input type="text" id="forename" onclick="this.value='';" onkeypress="this.value='';" />

Mmmm there's my first problem – I can’t simply add an onkeypress event as it would wipe out everything as I type… Not very user friendly.

Being lazy I was obviously annoyed at this as it meant I had to think about how to make this action accessible for all users…

Here’s a messy version of something that worked in my scenario:

<script>
<!--
function clearText(obj){
var defaultValue="DEFAULT VALUE";
if(obj.value==defaultValue){
obj.value="";
}
}
//-->
</script>

<input type="text" id="first_name" onclick="clearText(this);" onkeypress="clearText(this);" value="DEFAULT VALUE" />


It's messy but it does solve the problem and my page successfully got a WCAG priority 2.. AKA "a pass".

The point is you have to offer a solution to all of your users, not just those with a mouse. So next time you type that fatal line of code: onclick, remember those people who can't use a mouse.

I guess that is the concept of accessibility after all – allowing everyone to use your website!

"I don't care about accessibility"

Time and time again I come across clients saying "I don't care about accessibility just make it fixed sized fonts". You know the ones who don't understand that changing a relative fonts css file actually isn't a five second job? And that there isn't some big magic button you can press?

Well next time they want to break the law, become the first big name to get sued and have their image tarnished by all the hype that will surround them when it happens tell them this...

Good accessible websites can port easily to other devices such as mobiles, PDAs and other platforms due to the way they are coded – opening up a whole new market place for your products.

Coding in web standards, using semantic markup, also has another beneficial side effect – SEO – good semantic code means that search engines can understand your content in much the same way your users will be able to.

If that doesn't get them how about the massive percentage of potential customers they are alienating?

• There are 8.6 million registered disabled people in the UK which amounts to 14% of the population.

• Two million UK residents have a sight problem.

• One in 12 men and one in 200 women - 9% of the UK population - have some form of colour blindness

• 3.4 million people have mobility disabilities preventing them from using keyboards and/or a mouse in a conventional manner.

• Increase potential revenue streams: a seamless experience across different platforms/devices will help you prevent damage to your brand.

• Good usability & accessibility often goes hand in hand with higher organic search rankings.

Any good business person should want to increase their target audience and 14% is quite a hefty percentage to exclude.

Don't alienate potential customers - start to care about accessibility.

Writing Effective Website Content for SEO

“Think of your visitors”
What are your visitors going to be searching for? Is your site full of industry jargon which they probably won’t use in their search terms? How do users read your website? How often do you really read a webpage? …How often do you “skim-read” until you find the information you’re after? How do search engines read your webpages?

Turning off images and style sheets for your webpage is often a good indication of how effective the page is at conveying the information within it. Remember that search engines can’t read the fancy text, the beautiful images and all those colours.

This document is a guide to what can you do to make your site perform better in the search engines just by changing the way the content is written.
There is also another positive side effect to writing effective content for your website – accessibility. Remember some people can’t see your website (just like the search engines!) so making sure your content is effective will also aid those users’ experience of your website.

It costs nothing to do and is the single most effective way to boost your search engine rankings!
 
Make good use of page titles & headers
Ensure each of your website’s page has a unique title that describes the page well. The title is not actually shown on the webpage itself but it’s this text that appears in bookmarks, on the menu-bar of your browser and it’s what most search engines use as the title in their listings.

For instance, if your site title is "Dave’s Cars", a visitor may want to bookmark your home page and the page for a red convertible you have on the forecourt. If all of your pages have the title "Dave’s Cars", then a visitor will have trouble finding your site again in their bookmarks. If, on the other hand, your home page has the title "Dave’s Cars” and your page about that classy red convertible on the forecourt has the title "Red Convertible at Dave’s Cars", then visitors can glance at the title to see what it's about and can easily find it in the bookmarks later. Note that “at Dave’s Cars” comes at the end of the sentence… There’s a reason for this but we’ll get onto that later.

Search engines index pages based on the words contained in them, and including descriptive titles helps search engines know what the pages are about. The search engines will often compare your page titles to your page headings… Let’s review those now.
Breaking up text with descriptive headings and sub-headings allows site visitors to easily see what each section of the page is about.

The main heading (the H1 tag) on the page provides a brief overall view of what page is about. The opening paragraph should give a brief conclusion of the page (because you've “front-loaded” the page content… Again hold back we’ll get onto “front-loading”/”front-weighting” your content shortly).

The sub-headings (your H2, H3 etc tags) should group on-page content into logical groups, to allow site visitors to easily access the information that they're after. For example your main heading (H1 tag) may contain “Latest industry news”; your subheadings (H2 tags) may then be “United Kingdom”, “United States” etc if your news happens to be regional. If you wanted to further categorize your content you may add (H3 tags) such as “England”, “Wales” and so on.

Again this will help search engines understand how the content on your page is structured but it also has a positive effect for accessibility (as do most of the techniques in this document) as screen-readers use the headings to create links into sectors of your page so users can jump to relevant information in your page quickly and easily.

Use Bold Text & Italics
Another way to help users locate information quickly and easily is to bolden important words in some paragraphs. When site visitors scan through the screen this text stands out to them, so do make sure the text makes sense out of context.

Use descriptive link text
In the same way that bold text stands out to screen-scanning web users, so does link text. Link text such as ‘click here’ makes no sense whatsoever out of context so is useless to site visitors scanning web pages. To find out the destination of the link, site visitors have to hunt through the text both before and after the link text.

Screen-readers will also show users a list of links in the page… Understandably in this instance “click here”, “click here” and “click here” next to all of your top three news articles suddenly becomes pretty annoying and irrelevant.

Using lists
Using a bulleted or numbered list is a really simple and effective way to convey information. Lists are easier to scan for the user so they can quickly grasp your products key features quickly and easily and therefore ascertain whether or not it is relevant to them.
 
“Front-weighting” or “Front-loading” your Content
OK I’ve already mentioned this a couple of times but what is it?
Front-loading content means putting the conclusion first, followed by the what, how, where, when and why. The first line of each paragraph should contain the conclusion for that paragraph.

This theory all goes back to how users read your webpages… When you “read” a webpage you tend to scan it for the information you need… You’ll often read the first few words of a paragraph to ascertain what it’s about and then move on. This is why front-loading can be so effective.
Because each paragraph should contain just one idea, concept or theory users can do all this safe in the knowledge that if they jump to the next paragraph they won't be missing any important information.

Front-loading also applies to the entire web page, as well as paragraphs. The opening paragraph on every page should always contain the conclusion of that page. This way, site visitors can instantly gain an understanding of what the page is about and decide whether they want to read the page or not.

Unfortunately many websites don't adhere to this guideline and end up writing page content in a story-format. On each page there's an introduction, middle and conclusion, in that order. Unfortunately, when scanning through web content we don't tend to read all the text nor read all the way to the bottom of the screen. As such, you may easily miss the conclusion if it's left until the end.

Although there is no hard evidence to back up the theory that front-loading content can affect your search engine rankings it is fair to assume that search engines will evaluate the content of your page by first reading the title; then checking the H1 (your main heading) is relevant; then the subheadings; and then the body text to make sure that the page contains relevant content.
 
Common/ Key Words, Descriptions & Metadata
You may or may not be aware that you can apply “metadata” to your webpages. Metadata is a concept of tagging data - the dictionary definition actually says it’s “data about data”. For example in your local library books might be categorized into sections ie. “Children’s books” or “Biographies” this is metadata.

Webpages can store this information in custom tags that are added to your webpage called “metatags”. This information is not seen by the users when viewing your webpage but some search engines use this additional information to help index your webpages in their databases.

There are two main types of metadata tag that you can add to your document namely “keywords” and “description” – both are pretty descriptive of their use. Generally these tags are written by your webmaster or, more often than not, excluded altogether from a webpage - which can decrease your SEO rankings for some of the search engines.

Therefore including and writing these tags effectively, in the same way you would the rest of the content, is important. Be careful not to duplicate the first paragraph of your webpage in the description metatag and use it as an opportunity to describe your document in another way; where this description needs to sum up the entire page.

Some search engines use the description metatag as the “introduction” text in their listings so make sure it makes sense and presents your webpage in an enticing manner... It’s often the first snippet of information users will read about your webpage!

Using “Keywords” or Common Words
It may sound obvious, but if you want to rank highly in the search engines for a certain set of keywords, but don't use those keywords or phrases on your webpages, then ranking for those phrases will be difficult, if not impossible.

You can add these as a comma separated list in your “keywords” metatag but should also use them throughout your textual content so the search engines can match a users search terms (keywords) to your document.

I cannot emphasise enough the importance of choosing these keywords carefully. Always think of what your users will search for… For example if you were a watch manufacturer and your new product was named “Tickomatic 5000” it’s unlikely users will search for a “Tickomatic 5000” but they may search for: “watch”, “watches”, “timepieces” etc. If you’re struggling to think of keywords a good tip is to use a thesaurus for example http://thesaurus.reference.com

Be careful not to overuse keywords as some search engines will see it as “spamming” and blacklist your webpages from their indexes.
 
The use of images to convey information
Images on a site can look great - but search engines can't “read” them, and not all visitors can. Make sure your site is accessible and can be understood by visitors viewing your site with images turned off in their browsers, on mobile devices, and with screen readers. If you do that, search engines won't have any trouble. Some things that you can do to ensure this:

• Don't put the bulk of your text in images. Reserve images for graphical elements. If all of the text on your page is in an image, it becomes inaccessible.

• Take advantage of alt tags for your images that enhance the content – it’s a common mis-conception that “all” images should have alt text.

• Make sure that alt text is descriptive and unique. For instance, alt text such as "picture1" or "logo" doesn't provide much information about the image. "Charting the path of stock x" and "Company Y" give more details.

• Don't overload your alt text. Be descriptive, but don't stuff it with extra keywords – this can actually have a negative effect on SEO.

Whilst we’re on the subject…
Google Image Search enables you to opt-in to have your site’s images indexed. This enables Google to use your images in the “Google Image Labeler”, which harnesses the power of the community for adding metadata to your images.
 
Domain and file naming conventions
It used to be a common misconception, among many search engine optimization consultants, that filenames and domain names didn’t affect search engine ranking as it was pretty easy to name your file “cars-automobiles-motors-car-motorcar-automobile.html”, for example, and therefore spam the search engines with lots of keywords… Will I’m afraid they do have quite a dramatic effect.

You’ve probably seen several URLs with variables passed to them such as:
www.irrelvant-domain-name.com/news.asp?article=1234

Now take away everything you learnt thus far about writing your content.

Let’s say the above link goes to a page about the latest advances in medication for flu. Nothing in the domain name, or file name, tell us anything remotely related to our search terms of “medication for flu”. Now consider:

www.your-medication.com/viruses/flu/news/

Immediately we have three possible keywords in our URL that the search engine can relate our search too.

Try typing “medication for flu” into Google, for example. You’ll notice some of the top results contain keywords (in bold) as a part of the URL in the listings.

Therefore always try to name the files you create appropriately and place them into well-named folders on your web server as a quick and easy boost to your search engine rankings.

Odeon accessibility review

One thing I tend to do, sadly, is have a check back on sites after a while to see if the current editors are keeping up the accessibility standards and I have to say Odeon has started to slip unfortunately...

1. Proper use of header tags

For starters I've noticed more than one H1 per page... For example underneath the logo is a H1 with their phone number in! There should always only be one H1 so a user can see what the page is about in their headings list (a feature of common screen readers such as Jaws).

2. Badly implemented TabIndex

This one is terribly frustrating... The left nav has a single TabIndex applied halfway which jumps you straight to "something for everyone"! Obviously frustrating for those non-visual users and some mobility disadvantaged users who rely solely on the keyboard to navigate.

3. Bad use of Alt tags

Just hover over the user ratings... Intuitive isn't it?

4. Interesting random buttons

Take a look at a film page with Javascript disabled and you get two rather interesting new buttons appear underneath the film name... "Larger Size" and "Close". The Larger Size one is my favourite... This takes you to a popup that tells you you don't have javascript installed... Classic!

I think the point here is never promise your clients anything commital when it comes to accessibility - especially if you're relying on an editor with inadequate experience of accessibility, or content editing for the web in general... They will inevitably mess up all your hard work!

Is Flash actually accessible?

I've been having a bit of a read on Fadtastic recently about a very interesting article on the accessibility features of Adobe Flash.

As a massive fan of Flash, one of the most frustrating things for me was the lack of ability for an embedded object to return focus to it's parent page... Virtually rendering it inaccessible for obvious reasons.

However Johan, of http://designmatters.zoic.be/, has come up with a very interesting test which you can see here which opens up an interesting idea. Unfortunately it uses javascript to control the focus but it's certainly got me thinking.

I'll update you if we get anywhere!

Accesskey's are bad - UPDATE

Not long ago I wrote an accessibility article as to why accesskeys were a bad idea... Well I'd like to further that discussion with the release of FireFox 2.0, not so long ago, and a new issue that has arisen.

In a somewhat intuitive 'hack' to avoid access keys colliding with its browser shortcut keys the guys behind FireFox 2.0 introduced a new combination of keystrokes to implement accesskeys by adding the SHIFT key. Therefore to activate access keys in FireFox 2.0 the combination is now Shift+Alt+{key}. I.e. to activate an access key with the value of H would be Shift+Alt+H.

Great I hear you say... The combination no longer clashes with the browser's shortcut key i.e. pressing Alt+F will activate the File menu as expected. However inevitbaly (God I sound like such a pessimist!) this is by no means a great solution - just try holding down SHIFT+ALT+0 with one hand for example... Tricky isn't it?

On that note another issue is the fact that numeric access keys no longer work in FF2 (without accessing the config and changing the default settings that is). That means that the functionality of all accessibility optimised websites that have numeric values for access keys currently setup, will no longer work in FireFox 2.0.

Hands up who wants to tell all those accessibility gurus currently referring to the UK government's e-GIF recommendations?

Is Web 2.0 a step backwards for accessibility?

In a recent article on ZDNet Robin Christopherson, head of accessibility services at AbilityNet warns "Web 2.0 won't close the door, but it will make creating accessible websites fraught with many more potential pitfalls and you'll really have to keep your eye on the accessibility ball all the way through to make an accessible product at the end".

I guess this could be argued both ways, seperating content from the presentation layer is certinaly a fantastic step forward - it enhances search engine optimisation and undoubtedly makes the content more accessible to a wider range of browsers but the point Christopherson is trying to make is that user generated content can often lead to more problems than it solves.

Front loaded content: the principle of one idea per paragraph; is a valid point here... After all if you are allowing any Tom, Dick & Harry to enter content who is going to validate it?

Another valid point made is the use of Ajax based technologies and the fact that many companies are happy to jump on the band wagon without considering the users who can't use such technologies in their browsers.

I think the point here is that Web 2.0 isn't the cause and yet it certainly isn't the solution.

Make sure you check out the article here

Department of Trade and "Inaccessible"

A friend of mine, namely Pete Hobson of www.freesome.com fame, pointed me in the direction of an article about how the UK Government can't even follow their own accessibility guidelines when commisioning agencies to do their websites.

The site in question is the Department of Trade and Industry and with statements from their spokesman such as: "No assistive technologies were tested against the site."

It really makes you wonder why we bother doesn't it?

There isn't much else to say which hasn't been said in the article itself but it certainly makes interesting reading that's for sure!

Check out the article at: www.webstandards.org

Accesskeys and why you should remove them

I've recently removed accesskey technology from the Code Required website and continue not to use them on our latest projects.

Basically accesskeys were touted as a great accessibility tool a little over a year ago and the increased ubiquity of sites using them was immense. However, I'm now of the opinion that so many sites are implementing non-standard accesskey combinations that they are actually a hindrance to accessibility rather than an aid.

For example it was always my intention to use the acceskey key combination "ALT+1" to return to a site homepage; I have since seen various other key combinations such as "ALT+h", "ALT+0" etc etc.

Now far be it from me to stand and preach but I think until an adopted standard for these keys is used they are of little help to a user if they have to learn to use these.

My second, and perhaps even more valid consideration, is that accesskeys may actually override key combinations that users can create themselves in browsers such as Jaws. (OK so Jaws tends to use the INSERT key for most of it's key combinations but you get my point).

Therefore forcing a user to use your predefined key combinations is actually bad usability & comprimises "accessibility" as it were.

Educating the client when it comes to accessibility

I have recently been working on a new version of the Hackett website which I must admit caused us some headaches with accessibility - some I'm not sure we've solved at all - here at designuk which raised the point for me about how aware client's actually are about accessbility.

I mean 9 times out of 10 it appears agencies tend to take a marketeer and a designer when it comes to new projects... Maybe they'll throw in an account handler, to keep them under control, but only on very rare occasions is a development consultant included in the initial meetings - you only have to look at the recent dire consequences such as River Island and French Connection to know that's true.

I know for a fact Diesel can't/don't care about accessibility with the amount of Flash they use on their website(s)!!!

So if you work at an agency and as your company's accessibility advocat then stand up and be counted... In fact gone are the days when developers had to sit in the corner with their headphones and Metallica t-shirts on, stroking their goatee beards - it's time to stand up and be counted!

Only we can make a difference in educating the clients at the end of the day - not the arty farty designers or the marketeers with their acronyms and speil.

WATC Releases Toolbar Plug-in for Opera Browser

WATC released a new version of it's web accessibility toolbar for the Opera web browser. The toolbar includes a several built-in tools to aid developers and quality assurance testers design web sites that meet international accessibility requirements.

The IE version has been available for sometime and is also available as a free download.

Inclusive Web Design For All at the RNIB

I recently completed a course at the Royal National Institute for the Blind and have to say that if the vast array of courses that are appearing on the net at the moment are leaving you somewhat perplexed as to which to choose then go for this one!

Although most of the courses available will cover the same principles the RNIB course really has it cracked.

Inclusive Web Design For All isn't so much coding and technically orientated but based strongly on the principles of why the way you develop a page influences the end result.

At no point do they attempt to constrain design in anyway which is also incredibly refreshing but the key to why this course was so amazing?

Bim, the instructor wrote the course herself, is registered blind so it really hits home how important the issues are - this is from someone who really experiences the issues and not some techy geek who thinks they know it all!

Image Replacement with Accessibility and why Flash Replacement is Better

I've read so much about image replacement, and how bad it is for accessibility, over the last few months that I felt I really needed to throw my toys out of the pram and write something myself.

So what is image replacement?

Essentially image replacement uses JavaScript to search through a document's object model and replace certain tags with images... For example you might change "<h2>header</h2>" with "<h2><img src="headerNicelyStyled.gif"></h2>.

Why is this bad for accessibility?

The valid argument is that if I scale my text; images won't scale, so, it won't help users who need to use text resizing to view a page (or those who use Opera or similar re-rendering magnifiers will be presented with heavily pixelated images).

The solution?

Don't use it. sIFR is a new version of image replacement using Flash to render the font. If a user doesn't have Flash or JavaScript the tags will be left alone and presented with their css style aternative.

If they have both these technologies then they will be presented with flash file with the font embedded. Now the glory of this is that as long as you use relative sizing the flash movie can scale and the user can still benefit from magnification methods they are used to!

I've used it on several projects now and can't see any issue not to, but if you have a valid reason why this is bad for accessibility purposes, or indeed any other VALID reason, please do get in touch.

If this is all new to you please check out www.mikeindustries.com/sifr/.

Accessibility and the BBC websites

The BBC's "My Web My Way" directive has been attracting a lot of attention in recent months and they have again exceeded, certainly my, expectations and have commissioned System Concepts to produce an Accessibility study of bbc.co.uk which they are releasing to the general public for perusal.

Interestingly System Concepts actually use disabled users to evaluate using the site (as discussed in my meeting with the Shaw Trust) and the BBC have included details of the user findings in Appendix 6 of their document - it certainly makes interesting reading and can be downloaded from their site.

It all goes to show that not even the big guns get it right everytime - even if they do meet so called WAI guidelines!

Accessibility and anti-robot testing

One thing that PAS78 hopefully will bring to more people's attention is the use of graphics for anti-robot testing... Also known as the obscured numbers in a graphic that you have to type into a box to confirm your registration or if your a complete marketing-speil word-monkey then 'Captcha' or 'Turing testing'.
PAS78 raises the issue, quite rightly, that if a user has any type of sight impairment the use of this technology could in fact disable the use of these forms unless there is an alternative method available.

Hotmail does include an audio version of it's Captcha image, so that a user can listen to the numbers being read, and then enter them into the verfication form field (although if you have ever attempted to listen to one of these it's incredibly diffcult to inteprete what the hell is being said as they have distorted the sound to deter robots with sound analysis!)

Google has gone to the extent of using SMS to send a user a passcode, which is a novel idea, but SMS isn't completely accessible yet either so that isn't a solid solution - and let's face it - not exactly cost effective either if you have to set up an SMS gateway etc etc.

Unfortunately at the moment there is no surefire ideas on how to implement accessible Captcha methods... Virtually all methods can be hacked and using these methods of human detecting inevitably will be difficult to use for some users... A 'code' based system such as those mentioned above may be difficult for dyslexic users; The common 'distorted image' method is difficult for those with visual impairments; and so on and so on...

So what is the solution? Well I'm not about to answer that here but do make sure you consider these users next time you implement some form of anti-robot testing in your next application... Create an audio version if you are going to use the recognised 'distorted image' method, try to avoid complex logic and always consider ALL of your users!

related link

PAS78 : What's all the fuss about?

So PAS78 has been released now and the dust is starting to settle somewhat but my initial impressions are of some disappointment.

Although finally we have some solid statistics and analysis to convince our clients that developing a website with the broadest range of users in mind is welcoming, to say the very least, there is nothing new in the DRC's documentation - it's been the accepted norm that the W3C's Web Content Accessibility Guidelines are the guidelines that we should all be following for some time now.

So why all the fuss? Well that's something I still can't determine... I mean I genuinely hope that the government has decided to take more of a stance and enforce the Disability Discrimination Act of 1995, with regards to digital media formats, and was hoping that the PAS78 documentation might actually be an enforcement more than a general overview but I'm afraid that's exactly what it is.

So the conclusions are the same as before: consider what the site should do and for whom; consider who you are going to get to create it; consider how to enforce the guidelines; and consider how this can be tested.

So much hype; so much expectation; so little new information.

There are some valid points that I have tried to advocate on all projects I've worked on however:

Never rely solely on automated WCAG checking tools such as WatchFire and the like; try to actively envolve disabled people in your testing

Consider how disabled people might access your website - there is no substitute for working directly with people with a range of disabilities

Remember that most disabled people don't use assistive technology but rely on standard browser features such as text resizing

Compliance isn't all about design or the code you use - consider the way you present content and the wording you use

Consider whether the same functionality provided by client-side technologies such as javascript and flash can be achieved on the server before the data is presented to the user.

I'll be delving deeper into the guielines on a regular basis and providing my views and opinions on solutions to some of the issues raised so watch this space!

Check out the W3C's Web Content Accessibility Guidelines

Meeting with the Shaw Trust

I had the privelage of meeting some representatives of the Shaw Trust today regarding their work with disabled web users. Very very interesting and although I've been advocating accessibility guidelines for over a year now they certainly opend my eyes to some new ideas... The Shaw Trust works directly with disabled web users so has a really good understanding of exactly how they use the internet.

Our meeting coincided with the launch of the DDA's PAS78 Guidelines (which I'll be reviewing soon!) and between us we managed to raise some very interesting points:

Accesskey's and whether they are good are bad... What?? Yes we actually came to the conslusion that pre-defining acceskeys is a bad idea... For example what happens if they conflict with a usres browser shortcuts? Or, what if you've set a user defined shortcut in your browser so that ALT+G takes yo straight to Google? Ahhhh not so great now are they? The W3C guidelines state that defining accesskeys is a good thing so it'll be intersting to see what PAS78 makes of them.

There's no denying they are a great tool but for now I suggest you create a set of session variables which allows a user to define their own accesskeys and indeed allows them to be "turned on" or "off" accordingly.

related link

Accessiblity and DHTML Menus

The general consensus amongst users unfamiliar with what you can and can't do with web standards and accessibility is that javascript and accessibility don't mix? This is a total fallacy.

After much research the conclusion is that DHTML is fine. As long as the code is structured using lists and you give alternatives for users, such as "onkeypress" instead of "onclick" events ? basically drop-down-menus are perfectly feasible.

For example the top level DDM would have an "onclick" event to go to the top-level homepage. Then, for accessibility compatibility, we would add an "onkeypress" (and an access key) to the link so that users, unable to use a mouse, could also go directly to the page.

This is fine as the user will then see the full navigation on the subsequent page, or, for users using screen readers or non-visual browsers where the navigation would effectively be hidden, the navigation elements would be coded using pure web standards so that all of the navigation is "visible" to those users.

related link