E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Jon Gunderson
Date: Tue, Jan 23 2007 8:10AM
Subject: Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
No previous message | Next message →

A new version of the Illinois Functional Web Accessibility Evaluator (FAE v. 0.9.2) is now available:

http://fae.cita.uiuc.edu

---------------------------------------------------
Register for a free user account at:

http://fae.cita.uiuc.edu/register.php.

Benefits of user account:
1. View only reports you make when logged in
2. Archive reports up to 6 months

---------------------------------------------------
New features in Version 0.9.2:

1. Archived Reports list only those reports you create when logged into your user account

2. Fixed problems with character encodings and special characters.

3. HTML content stored in the results file (currently the title content) is assumed to be ISO-8859-1 and all named character entities defined for XHTML 1.0 are recognized.

4. A problem was fixed with proper escaping of ampersand ('&') characters in URLs.

5. Fixed problem with the test for form controls and labels. FAE now additionally detects 'input' elements with 'type' attribute value of 'checkbox' or 'radio'.

6. A problem in wget was fixed that prevented page requisites such as images from being downloaded and analyzed when 'Follow links in next-level subdomains' was selected.

7. Added favicon image for all FAE pages.


--


Jon Gunderson, Ph.D.
Director of IT Accessibility Services
Campus Information Technologies and Educational Services (CITES)
and
Coordinator of Assistive Communication and Information Technology
Disability Resources and Education Services (DRES)

Voice: (217) 244-5870
Fax: (217) 333-0248
Cell: (217) 714-6313

E-mail: = EMAIL ADDRESS REMOVED =

WWW: http://cita.rehab.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

From: Patrick H. Lauke
Date: Tue, Jan 23 2007 11:00AM
Subject: Re: Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
← Previous message | Next message →

Michael D. Roush wrote:

> Should I be using both the character encoding in the http header and in
> a <meta> tag? Should I remove the one set in the http header? Or
> should FAE allow the absence of the <meta> tag if the character encoding
> is set in the header?

I think an issue would arise once a user saves a page locally and
re-accesses it...in the absence of the header, in that case, the <meta>
is the only authoritive clue as to what encoding the page has.

So yes, I'd say use both.

P
--
Patrick H. Lauke

From: Robert Yonaitis
Date: Tue, Jan 23 2007 11:10AM
Subject: Re: Illinois Functional Web Accessibility Evaluator: Signup for free user acount
← Previous message | Next message →

Hello All:

On Headers: of course headers are used for many different things and not
excluding static pages. From encoding, Privacy, Session, P3P, meta
information of all types, are we saying that we need to consider all
information in our headers as needed to be duplicated? Should we have to
save our P3P file to a P3P xml?

Can we assume if a user is saving a page that they are OK with the
encoding, privacy and any other information and the duplication should
not be required and if we are recommending this are you recommending
this for only static pages or not just static but for both
static/dynamic and web applications. I ask this because, as we all know,
a developer will ask Why?!? do I need to duplicate "widely accepted
method of using http headers" in my application which can present a
whole set of issues for the <meta approach.

Perhaps this is where a tool needs to be able to Read the value it is
looking for in the header or in the meta information and grade it
correctly versus saying that it fails because it does not read the
header? JUST ASKING HERE.

Is there a set of test cases that the tool was developed against or a
logic case/use case for us to look at. I would be curious to see it!

Thank you all!

-Rob Yonaitis

From: Jon Gunderson
Date: Tue, Jan 23 2007 9:50PM
Subject: Re: Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
← Previous message | Next message →

In general most HTML validators require character encoding and the test is basically checking to see if the 3 elements needed for validation are present:

1. DOCTYPE
2. Character encoding information
3. Language specification

If these elements are present the author is more likely validating their web resources. If they are missing the author is probably not validating their resources.

Jon


---- Original message ----
>Date: Tue, 23 Jan 2007 13:05:18 -0500
>From: "Robert Yonaitis" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>
>Hello All:
>
>On Headers: of course headers are used for many different things and not
>excluding static pages. From encoding, Privacy, Session, P3P, meta
>information of all types, are we saying that we need to consider all
>information in our headers as needed to be duplicated? Should we have to
>save our P3P file to a P3P xml?
>
>Can we assume if a user is saving a page that they are OK with the
>encoding, privacy and any other information and the duplication should
>not be required and if we are recommending this are you recommending
>this for only static pages or not just static but for both
>static/dynamic and web applications. I ask this because, as we all know,
>a developer will ask Why?!? do I need to duplicate "widely accepted
>method of using http headers" in my application which can present a
>whole set of issues for the <meta approach.
>
>Perhaps this is where a tool needs to be able to Read the value it is
>looking for in the header or in the meta information and grade it
>correctly versus saying that it fails because it does not read the
>header? JUST ASKING HERE.
>
>Is there a set of test cases that the tool was developed against or a
>logic case/use case for us to look at. I would be curious to see it!
>
>Thank you all!
>
>-Rob Yonaitis
>
>
>

From: Robert Yonaitis
Date: Wed, Jan 24 2007 6:40AM
Subject: Re: Illinois Functional Web Accessibility Evaluator:Sign up for free user acount
← Previous message | Next message →

Jon/All,

Thanks for the clarification. So since we are using phrases like "In General" and "the author is probably" should we not do what is done in tons of validation suites and say WARNing, because something could probably be wrong versus telling all developers to rewrite their code which in cases could be rewriting an application? In the case of the headers they are easily read and then perhaps a WARNing on that, maybe some text,

"Warning, Character Encoding Found in the HTTP header but not in the STATIC source and this may imply a problem might exist"

This may be safer then having developers change their applications or dynamic code or even 1000's of static pages that admittedly could be done quickly if they decide is really required. By doing this the tool will have more value and be a aide to the developer and consultants doing any kind of testing.

What do you think?

Thanks,
Rob

From: Jon Gunderson
Date: Wed, Jan 24 2007 3:10PM
Subject: Re: Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
← Previous message | Next message →

Robert,
I am going to discuss this issue with our developers and this maybe an area where we want to provide a warning. Our current requirement is based on what HTML validation tools want to validate content [1,2].

I should also point out FAE [3] is designed to help people that are looking to do accessible design, rather than accessible repair. The tool is trying to direct people in making conscious accessible design decisions, not to try to fix content after it has already been designed. The result is that some of the tests will not be welcome to people who are just trying to fix up inaccessible designs.

Jon

1. W3C HTML Validation Service
http://validator.w3.org

2. Web Design Group Validtors
http://www.htmlhelp.com/tools/validator/

3. Functional Web Accessibility Evaluator
http://fae.cita.uiuc.edu

---- Original message ----
>Date: Wed, 24 Jan 2007 08:18:40 -0500
>From: "Robert Yonaitis" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Illinois Functional Web Accessibility Evaluator: Sign up for free user acount
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>
>Jon/All,
>
>Thanks for the clarification. So since we are using phrases like "In General" and "the author is probably" should we not do what is done in tons of validation suites and say WARNing, because something could probably be wrong versus telling all developers to rewrite their code which in cases could be rewriting an application? In the case of the headers they are easily read and then perhaps a WARNing on that, maybe some text,
>
>"Warning, Character Encoding Found in the HTTP header but not in the STATIC source and this may imply a problem might exist"
>
>This may be safer then having developers change their applications or dynamic code or even 1000's of static pages that admittedly could be done quickly if they decide is really required. By doing this the tool will have more value and be a aide to the developer and consultants doing any kind of testing.
>
>What do you think?
>
>Thanks,
>Rob
>
>

From: Robert Yonaitis
Date: Wed, Jan 24 2007 3:40PM
Subject: Re: Illinois Functional Web Accessibility Evaluator/OneLast Comment
← Previous message | Next message →

Jon:

Might help the users and the people on the list.

It would seem the method you are requiring is NOT the primary method
mentioned by the validator


Help for The W3C Markup Validation Service. Retrieved January
24, 2007, from W3C Web site: http://validator.w3.org/
docs/help.html#faq-charset


An HTML document should be served along with its character encoding.

Specifying a character encoding is "typically done by the web server
configuration," by the scripts that put together pages, and inside the
document itself. IANA maintains the list of official names for character
encodings (called charsets in this context). You can choose from a
number of encodings, though we recommend UTF-8 as particularly useful.


Cheers,
rob

From: Jon Gunderson
Date: Wed, Jan 24 2007 9:10PM
Subject: Re: Illinois Functional Web Accessibility Evaluator/One Last Comment
← Previous message | No next message

Character encoding issues are somewhat complex issues since there can be conflicting information provided by META tags and the HTTP headers. Many content developers may not control the web server settings for http headers and/or maybe unaware of how to set them.

Probably the most likely scenario for FAE is to only warn people if the META or XML tag is missing, since another potential source of author character encoding information is the XML tag in xhtml document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">


Jon


---- Original message ----
>Date: Wed, 24 Jan 2007 17:29:45 -0500
>From: "Robert Yonaitis" < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Illinois Functional Web Accessibility Evaluator/One Last Comment
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>Cc: Nick Hoyt < = EMAIL ADDRESS REMOVED = >, Dan Linder < = EMAIL ADDRESS REMOVED = >
>
>Jon:
>
>Might help the users and the people on the list.
>
>It would seem the method you are requiring is NOT the primary method
>mentioned by the validator
>
>
>Help for The W3C Markup Validation Service. Retrieved January
> 24, 2007, from W3C Web site: http://validator.w3.org/
> docs/help.html#faq-charset
>
>
>An HTML document should be served along with its character encoding.
>
>Specifying a character encoding is "typically done by the web server
>configuration," by the scripts that put together pages, and inside the
>document itself. IANA maintains the list of official names for character
>encodings (called charsets in this context). You can choose from a
>number of encodings, though we recommend UTF-8 as particularly useful.
>
>
>Cheers,
>rob
>
>
>
>
>