Accessibility Report

What are accessibility standards and who do they apply to?

Web accessibility standards are guidelines set by the W3C (World wide web consortium headed by Tim Berners-Lee the inventor of the web) to assist developers of internet software, including web browser software, and the developers/designers of website content that is to be displayed by any user agent for which they are intended, be it desktop personal computer, mobile cell phone or machine translation software such as employed on a screen reader for blind web users, to mention only some user agents, so that persons with disabilities are not discriminated against by web coding practices. The W3C's Web Accessibility Initiative page describes web accessibility and gives many links to further information.

Therefore, these standards apply to every instance of software and every website, whether on the web, an intranet, or on digital media such as DVD, unless you have written your own web display software to display your own webpage document content (html, xhtml, etc) according to your own set of requirements. In short, if you intend your webpage content to be displayed via standard, proprietory software, whether on or off the web, these standards apply to your webpage(s). Furthermore, the legal requirements concerning most governments' IT and Web documents, insist that their content be accessible to disabled persons.

---

Do you think accessibility standards are or are not important and why?

Web accessibility standards are extremely important especially since the "exponentially" explosive increase in the use of the web as we rush headlong into the 21st century, which includes increased usage by the permanently and temporarily disabled, extends to accessing education, employment, commerce, health care, recreation, banking, telephony, email, webmail, and voiceXML, large file transfer (U-send it, Mega-upload), religious programmes, and last but not least (well maybe), government. As little as 10 years ago it would have been difficult to imagine economically viable access to email, if at all, via a mobile cell telephone.

In Australia in 2006, a compulsory Australian Bureau of Statistics census poll requesting household information was available online to those with internet access via a series of web forms. It appears that while the pages themselves may or may not have been accessible, the server deployed to respond to page requests was severely overloaded, limiting accessibility in another, perhaps less considered manner.

Nevertheless, we can well imagine our previous list of online activities burgeoning considerably during coming decades, especially as disabled persons can use the web and services on the web to gain a degree of independence previously unavailable to them. Jeffery Zeldman in his book "Designing With Web Standards" points out, concerning web standards in general:

"Standards are vital to any medium. Because the software through which the web is viewed finally supports standards, it makes sense to learn about and correctly use them. Doing so saves time and money, reduces overhead, extends the usable life of our sites, and provides greater access to our content.

The latter point is important to anyone who wants to reach a wider audience particularly as nontraditional internet access increases. It also has legal implications as more nations and more U.S. states create and begin to enforce accessibility regulations. Web standards and accessibility can help your site stay on the right side of these laws."

To add further weight to the case for web accessibility standards, we may consider, not only the disabled, but persons who, for reasons of their own, choose to disable the display of images, audio, plugin content, etc, within their browser. We, as designers have no right to demand that they turn these functions back on. Thus, adherence to web standards in general, and web accessibility standards in particular, if we are to comply with and protect ourselves from accessibility laws as well as simply exercising consideration for others, makes, at least, good business sense if not plain old common sense (the latter being, ironically, rather uncommon).

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web

A link to the Top of page

---

Give an example of specific user groups with particular accessibility requirements.

Specific user groups requiring special accessibility considerations include those persons with disabilities such as blindness or near blindness, colour blindness, deafness and other hearing impediments such as a noisy environment. Persons unable to utilise a mouse or other pointing device due to mobility issues including amputees, victims of Parkinson's disease, muscular dystrophy, cerebal palsy and stroke all require special considerations as do those persons temporarily immobilised such as anyone with a broken arm(s), even parents nursing sleeping infants.

As stated above, anyone who, for whatever reason, has less than full implementation of browser or sensory functionality, such as persons accessing the net using mobile telephones, screen readers, those who's hardware is constructed or configured so as not to display certain functions, and especially if not specifically in this instance, disabled persons, must fall into this catergory. One may also consider a poor, overloaded student of Kingscliff TAFE Certificate IV in Web Design who's desk is covered in paperwork and simply cannot locate the mouse.

A link to the Top of page

---

What is an example of a General legislated accessibility standard and requirements

An example of a general legislated accessibilty standard is the Section 508 standards (ammended in 1998 to make Federal agencies electronic and information technology accessible to people with disabilities) which applies to all Australian government departments and agencies, and is implemented under the Disabilities Discrimination Act 1992- Section 5.

For example; Section 39 of the DISABILITY DISCRIMINATION ACT 1992 points out that is unlawful for a person who, whether for payment or not, provides goods or services, or makes facilities available to harass another person who:

• (a) wants to acquire the goods and services; and
• (b) has a disability

Section 39 could be easily interpreted to apply to websites (which it does since websites are a service). As well as this, Section 9.2.2 of the Section 508 standards specifically mentions websites and Section 9.2.3 outlines policy regarding compatability with assistive devices.

Even the wicked Macromedia Flash, oft regarded as the bane of accessibility, has implemented accessibility standards since the release of the MX version (twice superseeded as of October 2006) to permit compliance with Section 508. Macromedia have a section on their website wherin they assist users of their software to create accessible web content. The pages have this to say concerning plugins: "Plug-ins enable browsers to display a particular file format. Each plug-in requires a distinct strategy for accessibility. Under Section 508, the use of plug-ins must comply with standards for software. Similar to standards for web content, the software standards also require that the plug-in function without a mouse". Thus Section 508 can be seen to be no useless "paper tiger", and is certainly not lacking in scope.

The piccie is bit dated but you get the drift. Got it at CNN, shhhh!!

A link to the Top of page

---

Include a checklist of the WCAG 2.0 guidelines and whether your your front page adheres to the them

Guideline	Compliant or non-compliant
1. Provide equivalent alternatives to auditory and visual content	Compliant, alt tags and/or longdesc tag on all images on front page. No auditory content on front page.
2. Don't rely on color alone	Compliant, star image to mark headings, page divided into logical divisions, varied font size and style, underlined links.
3. Use markup and style sheets and do so properly	Compliant. Checked online.
4. Clarify natural language usage	Compliant, employed use of acronym and abreviation tags to describe what may be unfamiliar abreviations as well as acronyms.
5. Create tables that transform gracefully	No tables used on front page for layout purposes. Compliant on this page and log page, only tables used are for tabular data. One small nasty may be in that the breadcrumb title is contained within a one cell table tag. Dreamweaver speciality. If nothing else, at least it ensures that it will remain in place in a non-CSS compliant browser.
6. Ensure that pages featuring new technologies transform gracefully	Compliant, CSS used but pages will still display logically without CSS. Links division placed near top of page to ensure screen readers and robots encounter it first.
7. Ensure user control of time-sensitive content changes	Not applicable to the front page.
8. Ensure direct accessibility of embedded user interfaces	Compliant. CSS and XHTML tested.
9. Design for device-independence	Compliant. Simple page design "could be navigated with a television remote control". Links accessible via Tab key and subsequently the Enter key. Page content is accessible via keyboard up and down arrows.
10. Use interim solutions	Not applicable
11. Use W3C technologies and guidelines	Compliant, that's what we're doing here, right now, aren't we? Information is up to date as well.
12. Provide context and orientation information	Compliant, use of logical page divisioning, images, and heading and sub-heading structure.
13. Provide clear navigation mechanisms	Compliant, page has navigation section on RH side of page plus links at the bottom as well as back to top link. Every page is accessible from any page.
14. Ensure that documents are clear and simple	Semi-compliant, text could be bigger. Sacrificed font size to gain space.

 

A link to the Top of page

---

Test the web accessible conformation of your front page by using Web accessibility evaluation tools

1. Validate markup including syntax and style sheets, using following validators,

   * HTML Validation service Tested (see link to W3C on front page).
   * CSS Validation service Tested (see link to W3C on front page).

2. Use at least two Web accessibility evaluation tools on your index page

   *Tested with: Ocawa.    View saved report.

   *Tested with: Lynx Viewer.    View saved report.

   *And just to be a per-flamin-fectionist, tested with: Firefox HTML Tidy plugin.

   

Checkout the latest ocawa valid screenshot saved as a web page in Adobe Image Ready.

Index.html can't be better. Our front page is all valid xhtml and css as evidenced by the links to the W3C code validity testing services and the link to the Ocawa accessibility tester. The Lynx Inspected link shows that we can view the page as Lynx brower or, more importantly, how a screen reader would traverse the page. If it makes sense in a text only layout, chances are that a screen reader will also make sense of it.

So now we know how it's done, no problemo. Funnily enough, the Firefox HTML Tidy plugin found one point worth issuing a warning regarding an empty span tag on the Ocawa results page. I suspect, though, that the reason is that since there are no errors on the page and the page has the Priority 1 status, there are no remarks to deliver, so the empty span tag is the result of undelivered DHTML, which is a good thing, since if there were no errors on the Ocawa site, there would be errors on my page. I've heard of bitter irony but this is sweet irony, I guess.

Holy ciao. t3rry.

Quote:
jeffrey zeldman, “Designing With Web Standards, Second Edition”,
Publisher: Peachpit Press
Pub Date: July 06, 2006
Print ISBN-10: 0-321-38555-1
Print ISBN-13: 978-0-321-38555-0
The quoted passage appears in the introduction.

A link to the Top of page

---

 

::: © t3rry :: Kingscliff TAFE Certificate IV Web Design Portfolio 2006 :::