My OperaThis topic has been closed. No new entries allowed.
Reason: You can now post comments on articles on Dev Opera
You need to be logged in to post in the forums. If you do not have an account, please sign up first.
Building Accessible Static Navigation with CSS
When building a navigation menu for a web site, steps should be taken to ensure that it is accessible, and degrades gracefully in older browsers with lesser CSS support. In this article, Frank Palinkas explores one such implementation.( Read the article )
Frank
11. January 2008, 04:32:07 (edited)
Originally posted by Profesjonalna:
What can I say more then thank You Frank for this implementation! I use for some time CSS and I will try to do it on my new project.
You're most welcome Tomasz! I believe it's necessary to take the time and effort to make our web pages available to all users. Please experiment with this, change what you wish, and improve on it, moving foward together.
Frank
Frank
11. January 2008, 06:59:05 (edited)
Originally posted by azazul:
Emm ... thats wrong (in sense of semantics).
Why there is 4th level heading, but none of previous ?
And code aint valid too ..
It's HTML here you are using, so there is no <link />,
and.
It should be <link>,
and, am i wrong ?
=/
Hi azazul,
Thanks, and may I respond to your comments?
Heading Levels: The nav menu describes just one section of my web page. Considering the page:
- h1 is dedicated to topic name of the web page, normally placed in the masthead, and used once in a document.
- h2 is dedicated to secondary topics within the content section of the web page, and can be used repeatedly, depending on the nature of the content.
- h3 is dedicated to tertiary topics contained within the secondary h2 topics.
This planning of headings allows enough room to take care of most content topic needs. However, if there are no tertiary headings required within the content, then yes, the navigation headings will then be assigned the h3 element, and adjusted accordingly in the external style sheet. You've raised a valid point. This semantic order of headings becomes most obvious and needed in non-graphic user agents.
Closing "empty" elements:
When I write HTML as HTML, I follow the HTML 4.01 Strict specification using a Content/MIME type of text/html, and as a rule close all "empty" elements within the body element of the web page. In the head element of the web page, I keep the meta "empty" elements "open", as required by the spec.
When I write HTML as XML, I use the XHTML 1.1 specification with a Content/MIME type of application/xhtml+xml. The spec demands all elements be closed, regardless of their nature. Hope that explains it?
Frank
Frank
for me this approach to menu building is good from the point of accessibility, but anyway is giant in code. I suppose one can make it 1/3 smaller. Thank you for a nice reading!
Originally posted by tobto:
for me this approach to menu building is good from the point of accessibility, but anyway is giant in code. I suppose one can make it 1/3 smaller. Thank you for a nice reading!
You're welcome tobto,
If you feel like experimenting with it, please be my guest and share it with us?
Frank
Frank
Originally posted by jonyellow:
Making the menu more accessible is certainly a great idea, but the amount of code it takes to create is a bit discouraging. I'll work on it for a while and see if I can come up with any ideas to reduce code lenght a little.
Hi jonyellow,
As I also mentioned to tobto, please do so. If you see a better way forward, then all I ask is that you kindly share it with us.
Frank
Frank
Holy mackerel, that is the most complicated and convoluted navigation list I've seen in a long time.
When you've got an example of really complex code like that, it would be very helpful if you could post an example page that uses it, so that we can see it in action. I'm having trouble envisaging what it will look like and downloading and unzipping the files is not an efficient way for me to see it when you could put the page live on the internet.
My first thought is that anything as simple as a navigation list that has been made so complex it needs a key has been made TOO complex. Remember the basic rule - people spend most of their time NOT using your website, and they don't want to have to learn anything new in order to use your website.
What your method does is:
- add what looks like a navigation list at the top, but isn't, which will confuse people.
- add a layer of complexity to the menu by introducing lots of different icons, which will confuse people
- induce people to spend a lot longer looking at the menu trying to work out what is going on (ie they are confused) OR ignore the menu altogether (because it's too confusing).
You're aiming for something that degrades nicely, but you then add in even more confusion! You've put alt="ball symbol" on the image in the key, but anyone who can read the alt text won't see the ball symbol in the real menu because it's inserted with CSS so doesn't have any alt text. So the users will see that there are supposed to be ball symbols, chain symbols and so on, but will then just get a bulleted list of links - that's going to be confusing.
Yes, it's great to indicate the current page in some way - usually a background colour and/or a marker symbol are used. But surely the simplest way to stop people from clicking on it and wondering why they aren't being taken to a new page is to remove the link from that item in the list so that people can't click on it. Then mark visited links in a different colour/shade, and it's obvious to anyone who cares which pages they have been to.
The second thing that strikes me is how much redundant code there is in your CSS declarations. There are rules that are repeated identically in a:link, a:visited, a:hover and a:active. This is a recipe for disaster come maintenance or update time. Any rule that is common to some/all link states should be whipped out and placed in a separate a {...} declaration - that way you can't accidentally change it for one link state and not another. You can reduce the border declarations substantially as well, by combining them into:
border: 1px solid;
border-color: #aaa #aaa #fff #fff; (or whatever order it was)
Much more compact and easier to work with than specifying the weight and line style for each side of the border.
This seems to me like a prime example of "too much accessibility" - in trying to make it more accessible, you've actually made it a lot harder for most people - combined with hideously verbose CSS that will be an absolutely nightmare to work with.
When you've got an example of really complex code like that, it would be very helpful if you could post an example page that uses it, so that we can see it in action. I'm having trouble envisaging what it will look like and downloading and unzipping the files is not an efficient way for me to see it when you could put the page live on the internet.
My first thought is that anything as simple as a navigation list that has been made so complex it needs a key has been made TOO complex. Remember the basic rule - people spend most of their time NOT using your website, and they don't want to have to learn anything new in order to use your website.
What your method does is:
- add what looks like a navigation list at the top, but isn't, which will confuse people.
- add a layer of complexity to the menu by introducing lots of different icons, which will confuse people
- induce people to spend a lot longer looking at the menu trying to work out what is going on (ie they are confused) OR ignore the menu altogether (because it's too confusing).
You're aiming for something that degrades nicely, but you then add in even more confusion! You've put alt="ball symbol" on the image in the key, but anyone who can read the alt text won't see the ball symbol in the real menu because it's inserted with CSS so doesn't have any alt text. So the users will see that there are supposed to be ball symbols, chain symbols and so on, but will then just get a bulleted list of links - that's going to be confusing.
Yes, it's great to indicate the current page in some way - usually a background colour and/or a marker symbol are used. But surely the simplest way to stop people from clicking on it and wondering why they aren't being taken to a new page is to remove the link from that item in the list so that people can't click on it. Then mark visited links in a different colour/shade, and it's obvious to anyone who cares which pages they have been to.
The second thing that strikes me is how much redundant code there is in your CSS declarations. There are rules that are repeated identically in a:link, a:visited, a:hover and a:active. This is a recipe for disaster come maintenance or update time. Any rule that is common to some/all link states should be whipped out and placed in a separate a {...} declaration - that way you can't accidentally change it for one link state and not another. You can reduce the border declarations substantially as well, by combining them into:
border: 1px solid;
border-color: #aaa #aaa #fff #fff; (or whatever order it was)
Much more compact and easier to work with than specifying the weight and line style for each side of the border.
This seems to me like a prime example of "too much accessibility" - in trying to make it more accessible, you've actually made it a lot harder for most people - combined with hideously verbose CSS that will be an absolutely nightmare to work with.
Thank you,man!
You help me a lot!
You help me a lot!
<a href="http://www.voicent.com/ivr.php?a=8223">IVR</a>