Testing Conformance to Web Content Accessibility Guidelines

[kgun]

1. Background this page:

http://www.w3schools.com/tcpip/default.asp

WAI-A accessible.

2. Testing: My two sites:

http://www.adschoolworld.com/ WAI-A accessible.

http://www.ad-university.com/ WAI-AA accessible.

There is difference between the two sites.

3. Have I made any mistakes?

There is a reason for nearly hiding the link at the right edge. There is a reason for making it less accessible.

Should I remove the link to AdSchoolWorld and / or DigitalPunkt on Ad-University?

Why not recquire WAI-AAA accessibility?

My personal reason:

To require WAI-AAA accessibility, a site should IMO have audio and video of the message or is that not necessary?

4. Silence at WebProWorld is interpreted as acceptance.

[weegillis]

You will forgive me, I hope, for being forward... You're kidding, right? I mean, about the acceptance part. That's hardly the case, here, one would think.

Sometimes it's just plain hard to get the gist of the question. Could you please elaborate for us the purpose of these pages/websites? Perhaps then it would be easier to ascertain the advice you seek.

Thanks, Roy

[kgun]

Have you understood my point? You have no site so I can not check it.

It is not about content, even if I see those ranked important links as important content.

Read the title once more. May be you have misunderstood my question.

Do you need my advice like jtracking (http://www.webproworld.com/viewtopic.php?t=67909&start=25)?


Sometimes it's just plain hard to get the gist of the question. Could you please elaborate for us the purpose of these pages/websites? Perhaps then it would be easier to ascertain the advice you seek.
Thanks, Roy


Look at the URL and come back in a year and ask about the purpose.

[weegillis]

Oh, I get it now: Link Farm.

All this time I've been wondering what SEO meant, now I know: Scare Everyone Off.

In a year's time might we expect these sites to have as many hundreds of OBLs as the rest of your pages? I'll pass, thank you.

[kgun]

I try a last time. You can still not give a constructive answer to the simple task this test is about:

XHTML Validation and accessibility of internet pages. This is a simple example, and I intend to start simple.

What you call it is not important to me. The OBL's will on these two sites, especially on Ad-University, be much more foccused that the rest of my sites.

[weegillis]

WCAG 1.0 dos not require audio or video. It doe's recommend that if audio is present, a text transcript must be available for those by whom it cannot be easily heard. Video will require significant long description, much more than a straight photograph. This goes to Alternate Content which is highly recommended.

Audible text reading, if needed, will be supplied by the screen reader; i.e., JAWS.

The main purpose of the guidelines is to help developers structure and tag their sites in a manner that does not restrict access to any of the content.

For most purposes we can divide a page into two areas: content and layout. Anything that is strictly intended to visually enhance the page, with no direct value to the content, is layout, and need not be accessible, per sae. For example, images may be inserted in the page with CSS, rather than image tags, and would not require descriptive text.

The site should be fully functional when read as plain text. Image backgrounds and text foregrounds make for the most accessible visual navigation. Bear in mind that site navigation is more closely related to content than one might expect since it needs to meet with the same guidelines.

Anything relating directly to content must be accessible to assistive technologies. The guidelines go into great detail on how to properly structure and tag our pages so that this may be achieved.

One of the things that is less obvious in the guidelines, but nonetheless stipulated, is the level of confusion. We are encouraged to make our pages simple to follow and use. Many users may have full use of their senses while lacking the acumen and comprehension strengths needed to successfully complete a task on the internet. Taking as much confusion out of the page as possible is the goal, here.

To this end, there are guidelines that recommend effective methods of listing multiple links, including (but not exclusive to) correct use of title attributes and link text, proper separation of links so they can be distinguished when stylesheets are turned off, non-repitition of link text when the href points to a different URL; link phrases that make sense when taken out of context; and so on.

Other concerns deal with such things as accessible tables (include summary, caption, column and row headings and scope) and accessible forms (include legend, label and optgroup). Then there are such things as, Skip Links navigation to get around long lists of links and jump straight to the main content; image replacement text for images used as text or links, or both; meaningful outline structure (headings properly nested,etc.); the meaning of colors, when colored text has special meaning, adequate contrast between foreground and background and the use of colors that permit objects and text to remain distinct in the experience of users with color blindness; the accessibility of controls in forms and active content; the use of script and noscript, and inline event handlers; and the list goes on.

Let's not leave out the need for scalability, consistency in site/page navigation and layout in general, breadcrumb trails, enlarged link target zones, short pages that require very little scrolling, and so on.

As much detail as the guidelines go into, the list is still short enough to 'grow into' in a such a way that coding practices gradually incorporate in one way or another all of the salient points. It just takes practice and a willingness to go back and do it again, and again until it works.

It does come down to User Checks, in the end. Automated validators can only examine the physical page in its code form. The developer needs to examine and evaluate the actual webpage against the list of guidelines. The best way to learn is to do it.

If you run up against a problem, WPW must have dozens of folks who can help. In my experience, they are not likely to go looking for your problems, though, and most times won't point out the ones they discover--they'll keep that to themselves, good natured people that they are. Analytical criticism is not something you'll get here.

[kgun]

WCAG 1.0 dos not require audio or video. It doe's recommend that if audio is present, a text transcript must be available for those by whom it cannot be easily heard. Video will require significant long description, much more than a straight photograph. This goes to Alternate Content which is highly recommended.


This is conctructive critique.



Audible text reading, if needed, will be supplied by the screen reader; i.e., JAWS.


Please elaborate on this if you have time.



The main purpose of the guidelines is to help developers structure and tag their sites in a manner that does not restrict access to any of the content.


Yes.



For most purposes we can divide a page into two areas: content and layout. Anything that is strictly intended to visually enhance the page, with no direct value to the content, is layout, and need not be accessible, per sae. For example, images may be inserted in the page with CSS, rather than image tags, and would not require descriptive text.


Yes, and this layout and design that are separted from content may be implemented in different classes (API) that can be reused and where code automatically validates. The API (classes) is written once and included where you want to use it. Loose idea of some validation classes:

XhmlClass
Three WAIG child classes that inherit stucture from one parent WAIG class.
Various P3P Classes (http://www.w3.org/P3P/).
Other related classes and may be some very specific classes that inherits structure from more than one of the above classes (multiple inheritance).




The site should be fully functional when read as plain text. Image backgrounds and text foregrounds make for the most accessible visual navigation. Bear in mind that site navigation is more closely related to content than one might expect since it needs to meet with the same guidelines.

Anything relating directly to content must be accessible to assistive technologies. The guidelines go into great detail on how to properly structure and tag our pages so that this may be achieved.

One of the things that is less obvious in the guidelines, but nonetheless stipulated, is the level of confusion. We are encouraged to make our pages simple to follow and use. Many users may have full use of their senses while lacking the acumen and comprehension strengths needed to successfully complete a task on the internet. Taking as much confusion out of the page as possible is the goal, here.


My colouring. That confusion is taken out by a well structured validation class library.

The different classes are made once and code in the API satisfy various validation requirements depending on which super or subclass you use. Your job is to write content (the easy part of the job) that also validates in accordance with the specific API (class(es)) you use.



To this end, there are guidelines that recommend effective methods of listing multiple links, including (but not exclusive to) correct use of title attributes and link text, proper separation of links so they can be distinguished when stylesheets are turned off, non-repitition of link text when the href points to a different URL; link phrases that make sense when taken out of context; and so on.

Other concerns deal with such things as accessible tables (include summary, caption, column and row headings and scope) and accessible forms (include legend, label and optgroup). Then there are such things as, Skip Links navigation to get around long lists of links and jump straight to the main content; image replacement text for images used as text or links, or both; meaningful outline structure (headings properly nested,etc.); the meaning of colors, when colored text has special meaning, adequate contrast between foreground and background and the use of colors that permit objects and text to remain distinct in the experience of users with color blindness; the accessibility of controls in forms and active content; the use of script and noscript, and inline event handlers; and the list goes on.

Let's not leave out the need for scalability, consistency in site/page navigation and layout in general, breadcrumb trails, enlarged link target zones, short pages that require very little scrolling, and so on.

As much detail as the guidelines go into, the list is still short enough to 'grow into' in a such a way that coding practices gradually incorporate in one way or another all of the salient points. It just takes practice and a willingness to go back and do it again, and again until it works.

It does come down to User Checks, in the end. Automated validators can only examine the physical page in its code form. The developer needs to examine and evaluate the actual webpage against the list of guidelines. The best way to learn is to do it.


Great remarks.



If you run up against a problem, WPW must have dozens of folks who can help. In my experience, they are not likely to go looking for your problems, though, and most times won't point out the ones they discover--they'll keep that to themselves, good natured people that they are. Analytical criticism is not something you'll get here.


I think I need to write the classes that use PHP and MySQL (content system) myself. I asked for input. Some of my background here: A matrix class that illustrates the use of templates etc (http://www.forumnorway.com/viewtopic.php?t=500) and here (http://www.blognorway.com/) (lower left corner) so we do not misuse each others time and going off topic and filling up WPW's servers with nonsense another time.

After all, thank you very much for conctructive feedback this time. I hope other will contribute, since this is the future of the internet and an very important subject. The next generation of web pages requires more than yesterdays.

[Webnauts]

Kgun, I had a look on the fly at this thread, but I did not read everything yet.

If you need any help, PM me and remind me to have a look again.

By the way, if you have some minutes, I think you might would like to read a recent article of mine:
Accessibility Testing (http://www.webnauts.net/accessibility-testing.html)

[weegillis]

Here is a link on the Government of Canada's website relating to Assistive Technologies; perhaps it will help with respect to JAWS and others:
Assistive Technology Links (http://www.at-links.gc.ca/IndexE.asp)

I must confess that this area is not my forte, being as I am a single, volunteer webmaster/developer with zilch in the way of resources. The standards have helped me to 'prepare' the sites I build and maintain, such that an expert would have well formed code to build upon, should one ever happen along.

When you start getting into classes and APIs, you lose me, but I suspect not many others. This is where it would be best for me to hold my tongue...

[Webnauts]

1. Background this page:

http://www.w3schools.com/tcpip/default.asp

WAI-A accessible.

2. Testing: My two sites:

http://www.adschoolworld.com/ WAI-A accessible.

http://www.ad-university.com/ WAI-AA accessible.

There is difference between the two sites.
How did you test those sites. With automated tools?
That is not an evidence that they meet the requirements for WAI-A or WAI-AA.

Tests require human review and real users with disabilities: http://www.webnauts.net/accessibility-testing.html



There is a reason for nearly hiding the link at the right edge. There is a reason for making it less accessible.

Should I remove the link to AdSchoolWorld and / or DigitalPunkt on Ad-University?
I did not check the pages yet, as I wanted to ask first, which reason you have for doing that?


Why not recquire WAI-AAA accessibility?

My personal reason:

To require WAI-AAA accessibility, a site should IMO have audio and video of the message or is that not necessary?
That is only your opinion. But on the other way around, if you have audio or video, they SHOULD be captioned.

Your idea is cool, as it is an enhanced usability issue for people with disabilities, adding audio files with the page content read out. :)


4. Silence at WebProWorld is interpreted as acceptance.
Here I can only say: LOL

Hey I am very happy to see that you are concerned about accessibility. And you can be sure that I am always there to help, if someone is willing to learn and implement accessible web sites.

By the way, I am starting an online course in January: http://www.webnauts.net/academy/online-web-accessibility-courses.html

Best,

John

[Webnauts]

Here is a link on the Government of Canada's website relating to Assistive Technologies; perhaps it will help with respect to JAWS and others:
Assistive Technology Links (http://www.at-links.gc.ca/IndexE.asp)
I would suggest you to have a look here too: http://redish.net/content/papers/interactions.html

[kgun]

There is difference between the two sites.
How did you test those sites. With automated tools?
That is not an evidence that they meet the requirements for WAI-A or WAI-AA.


No my own subjective judegement.



Your idea is cool, as it is an enhanced usability issue for people with disabilities, adding audio files with the page content read out. :)


OK.




4. Silence at WebProWorld is interpreted as acceptance.
Here I can only say: LOL


That is a Norwegian saying. Silence = Acceptance or more precise Agreement. ("Den som tier samtykker") (or ignorance my words).



Hey I am very happy to see that you are concerned about accessibility. And you can be sure that I am always there to help, if someone is willing to learn and implement accessible web sites.

By the way, I am starting an online course in January: http://www.webnauts.net/academy/online-web-accessibility-courses.html

Best,
John


I am not overly concerned. As I wrote in another thread: Building Excellent Web Sites for Humans & Search (http://www.webproworld.com/viewtopic.php?t=68460&highlight=)

"If a site is good enough on:
accessibility, usability and humanfriendliness, it can, IMO, be excellent if it has excellent content. But it can not be excellent if it is excellent on accessibility, usability and humanfriendliness but not on content".

My underline. I try to make good enough, code and design and concentrate on content. Ranked links are content in my view. And I use too much time on this forum.

[Webnauts]

"If a site is good enough on:
accessibility, usability and humanfriendliness, it can, IMO, be excellent if it has excellent content. But it can not be excellent if it is excellent on accessibility, usability and humanfriendliness but not on content".
Not on content? I think you are kidding me, or not?

1. http://www.w3.org/TR/WCAG10/#context-and-orientation

2. http://www.w3.org/TR/WCAG10/#gl-abbreviated-and-foreign

3. http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension

[kgun]

My remarks in blue:



"If a site is good enough on:
accessibility, usability and humanfriendliness, it can, IMO, be excellent if it has excellent content. But it can not be excellent if it is excellent on accessibility, usability and humanfriendliness but not on content".
Not on content? I think you are kidding me, or not?

To be more precise IMO:
It is a necessary and a suffcient condition for a site to be excellent if it is excellent on content and good enough on code (XHTML, CSS ... valid), accessibility (WAI-1 as a minimum), usability, design and ...

1. http://www.w3.org/TR/WCAG10/#context-and-orientation

"2.2 Making Content Understandable and Navigable". Good enough is good enough here.

2. http://www.w3.org/TR/WCAG10/#gl-abbreviated-and-foreign

"Guideline 4. Clarify natural language usage.
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text".

Important but not enough to make a site excellent.


3. http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension

"Guideline 14. Ensure that documents are clear and simple".

Do you remember my old signature. Make it simple, as simple as possible but no simpler.

Conclusion:

A site that is excellent on content can be excellent if it is good enough on design, code, accessibility, navigation, consistency and usability.
A site that is excellent on content can be outstanding if it is excellent on design, code, accessibility, navigation, consistency and usability.



Your thread: "Building Excellent Web Sites for Humans & Search (http://www.webproworld.com/viewtopic.php?t=68460&highlight=)" is a related, but different topic. Back to topic?

[Webnauts]

Ah, now I got it man.

I am missing in my quote:

Good content! :)

I got it buddy. Thanks.