E-mail List Archives

Search E-mail List Archives for

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

From: Terence de Giere
Date: Thu, Apr 24 2003 10:48AM
Subject: Accessibility of dotNET
No previous message | No next message

Lisa

I have not used dotNet myself.

HTML
While the HTML sample you submitted looked rather messy, because the
doctype was HTML 4.0, I opened the page sample in an SGML editor. It
actually wasn't too bad. I had to add the attribute
type="text/javascript" to the script element, and remove the Microsoft
proprietary MS_POSITIONING attribute from the BODY element, and convert
the XHTML syntax that some of the elements had back to HTML. Valid HTML
is not a requirement for 508. Having a doctype declaration is also not
necessary for 508. But if you wanted to meet Priority 2 on the W3C
accessibility scale, this page is not HTML 4.0 compliant. I was able to
add the LABEL element without any problems. See if the dotNet tools
allow adding the LABEL element somewhere. The ID attribute required for
the 'for' attribute of the LABEL is already in the FORM controls. If the
dotNet page layout software is like MS FrontPage, one can insert a form
control, place the cursor in the position where one wants the label, and
type the label text, then select both the label text and the form
control and choose insert->form->label from the insert menu and the
LABEL element and the explicit association will be created.

GENERATED CODE
As for the dotNet ASP controls generating code you may have to just test
the resulting code against the accessibility guidelines you are
applying. Any system that manages and generates content and code has to
be checked because the developers of these systems might be ignorant of
accessibility issues to the degree needed for your applications, or just
don't care. I was curious about this and after some searching on the Web
found very little concerning dotNet and accessibility. Most products
these days still seem to have accessibility compliance issues
superficially tacked on so the vendor can say the product has 508
compliance for sale to the U.S. Government, but when you look at the
product accessibility resolution is not well integrated into the
package. One has to check what accessibility it really supports, and
particularly, what accessibility it might destroy. For example, manually
create a web page in valid HTML or XHTML with an assembly all the
elements in your site that need to be compliant, properly coded and
tested for accessibility, and then see if the system can save and
manipulate the page without fatally altering it as far as accessibility
is concerned. I have seen a content management system strip out the
LABEL element and other elements because it had a deficient internal
definition of what HTML elements should be in a page based on the then
current Microsoft and Netscape browsers but not on Web standards, which
supported these elements..

LABELS and POSITIONING and STYLE SHEETS
Absolute positioning is not a problem for Section 508 rules compliance.
Relative sizing is a W3C Priority 2 issue. However there is one
significant pitfall to watch out for when constructing a graphical page
with graphical tools that use absolute positioning. In your sample page
the label for the "number of days" (not a label yet in this sample but a
SPAN element) is right at the beginning of the form after the the
"title" of the form (also a SPAN element), but the form control, a
SELECT box, is near the bottom of the form. Text browsers, and readers
that do not support the explicit association of LABEL with the
associated form control will have a big usability problem here because
the label and the control are nearly at opposite ends of the form,
although the absolute positioning makes it look as if they are together.
For 508 compliance, a page must be also usable if style sheets are
turned off or unsupported, in which case visual browsers will also show
the label in a confusing place unrelated to the control.

SUMMARY
For this sample it is necessary to add the LABEL element and the LABEL
element 'for' attribute to the form controls and also make sure the
LABELs are next to their controls in the code in a way that makes sense
when style sheets are turned off.. Note this form requires JavaScript
and will not work when JavaScript is disabled or unsupported. A truly
accessible form always needs to be submitted to a server, using standard
non-scripted form submission to a server HTTP address where a
server-side application processes the request and returns a new page to
the user with whatever it is they need to know. If a form is scripted,
some kind of alternative should be provided. In the ambiguous words of
Section 508 rules "1194.22 (l) When pages utilize scripting languages to
display content, or to create interface elements, the information
provided by the script shall be identified with functional text that can
be read by assistive technology." The W3C is a bit more useful "6.3
Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible
page. (Priority 1)"

Terence de Giere
= EMAIL ADDRESS REMOVED =

-------------------
Lisa Cohen wrote:

As an ASP developer who is just beginning to look at developing pages using
ASP.NET and C#, I am finding very little information on the accessibility of
the ASP.NET objects





----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/