Quite a few of the sites you visit now, are coded in fairly unique ways. People are beginning to realize why things like table-coded layouts, older revisions of markup language and HTML styling, are bad for users. Most of the users who will have problems when viewing poorly coded pages are the visually impaired and people who cannot or prefer not to use mice, such as users with large printed keyboards for things like arthritis or muscle control problems. In this article, I will (attempt) to outline some things that you can do to keep your page as easy to use for as many of your users as possible.
Images
Starting with the basics. Users who are visually impaired often used text-based browsers. Now, a text based browser obviously only renders text and not images. For this reason, all images should have an
alt attribute. This provides browsers with alternative text that it can display on the page when an image cannot be found, images are disabled, or the browser doesn't support images to begin with. This is really easy to do, as can be seen:
Code:
<img src="images/logo.png" alt="matthewstyles.net - (slogan)" />
Obviously, if there was a slogan on the logo, you would put a slogan in after the dash. Just because people can't see images, doesn't mean fancy slogans and company names won't make a difference!! The only other thing you should do, is if you have a long description for an image, such as a diagram, a long description alternative should be given. In text-based browsers a long description isn't rendered directly into the user's viewport. The long description will be viewable on hovering over the alternative text attribute (which should also be there if it can be - not important though) or when the image is clicked, providing it isn't a hyperlink. The attribute for long descriptions is used in the same way as
alt, but is
longdesc.
Either of these two must also be used on media such as audio, video, image maps and even spacer images (the alternative text would simply be
'spacer image').
Client-Side Scripting
A lot of sites use scripts. Ever since JavaScript released their first specification and E4X was defined, people have been making scripts that create special effects and enhance pages. The key word here being 'enhanced'. Often I see web pages that have been virtually completely client-side scripted. The problem with this is, around about 5-10% of Internet users don't have a JavaScript enabled browser or disable scripting functions for one or more reasons.
There's not a lot to say on this topic, but just bear in mind to provide alternatives to users who don't have client-side scripting enabled in their browser. For example, the lightbox script that's became popular, I would use, but also provide an alternative where the image will pop open in a new window for these users.
Also, one thing to keep track of, is how your page's content is delivered. Content can be printed on pages by functions built into scripting engines, but then if the user doesn't have scripting enabled, they can't view the content. This simply defies the point of having the page in the first place to these users. Functions in JavaScript (such as
document.write), were intended for enhancements, such as printing markup that floats an element in the corner of a page as the user scrolls. You would only use this function to print the
extra HTML required to do this and leave it so that the rest of your users have a static menu left at the top of the page.
Scrolling text and Blinks
To be fair, the blink CSS property isn't widely used any more and the same goes for the HTML element. these firstly, aren't actually valid HTML. By all means, if Microsoft made a HTML or CSS validator, these would run through without any problems, but at the end of the day our web standards are set out by the W3C and not the creators of MSHTML (an extended version of HTML which often works only ion Trident engine browsers such as Internet Explorer). Blinking text is hard to read, especially if it is set to blink rapidly. This isn't meant for text-based browsers as such, but rather all users. Epileptic people, users sensitive to headaches and migrains and the general pool of public users don't like text flashing in and out directly in front of them to stress a badly-worded point.
The same reasons stand for scrolling text. Scrolling and blinking text might be hard to read for non-English users. People who speak other languages as their first language might find English hard to read as it is. Slow readers definitely wouldn't appreciate it, as text is moving from their screen as they're trying to read it. Users will simply get frustrated and leave the site.
Key rule here: don't use them!!
Tables
Tables are good. I already mentioned that table-based layouts should not be used, and that is discussed in detail in other threads round and about the forums. But tables were put into the HTML specification for a reason. They are used for displaying tabular data. But there are rules which apply when you mark out tables as well. Row and column headers must be clearly set out. This is done using the
th element. Example:
Code:
<table summary="Browser Trend Report - September 2006">
<caption>Browser Trend Report - September 2006</caption>
<tr>
<th>Browser</th>
<th>Market Percentage</th>
</tr>
<tr>
<td>Internet Explorer</td>
<td>65%</td>
</tr>
</table>
I actually went ahead and explained by next two points in the same example. Tables should have a caption to them. This is pretty much like a title, although if the title has been displayed above or next to the table already, then there's not a strict need for it. It's best to do table captions using this method though, just for getting your page through an accessibility validator. Captions can be ste using the
caption elements.
Lastly for tables, they should also have a summary. This is set using the
summary attribute set for the
table element. A summary is not always the same as the caption. if you have multiple tables on one page, the summary for each table may just be, for instance, a month and year number, whilst a caption would be the full title.
Frames
I don't know if frames are included in Strict markup specifications or not, and to be perfectly honest I don't care
Frames shouldn't be used because they're ugly. It was a trend that went out about 2 years ago and shouldn't be coming back any time soon. But back to accessibility.
A screen reader is made for single pages. If there are 2 or more pages, then a screen reader may or may not be able to read them all. It varies from browser to browser, but some users also disable frames. Reason being, you can user frames for submitting data into multiple forms, submitting multiple forms, forcing clients to click ads and so forth. Also, they are often sized using absolute measures rather than relative ones (e.g. in pixels and such). This makes it hard to read if the user's browser has been made to increase text size and such as the text will flow out of the frame and horizontal scrollbars.
End of.
I'm not an article writer by the way, so comments and suggestions are welcome
Linear Mode
Forum Contains New Posts 
Forum Contains No New Posts 
Forum is Closed