Thread Subject: Re: Valid and well-formed code
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Hoffman, Allen
Date: Mon, Apr 02 2007 7:15 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Eric Damery: "Re: Valid and well-formed code"
- Previous message in thread: Smith, Jamie: "Re: Valid and well-formed code"
- Messages sorted by: Author | Thread | Date
Personally I'd like to hear from the AT developers on this one.
I'm all for correct coding, but the reality is that there's a lot of
wiggle room out there, and user-agents handle that in quite a range of
ways, from strict, to very loose. While I think we should set the bar
for "accessibility", lets make sure we don't support that bar with
external factors that are already being managed successfully without
great burden. If, however, dealing with less-than well formed HTML
content being provided by user-agents is a great burden on At
developers, what would they find the benefit from lower that bar be? I
suspect it would be little benefit for them as they will have to keep
dealing with invalid content coding in any event to provide a real level
of assistance to end-users.
I'd hate for my screen reader to start telling me it can't interpret
page content because of a minor code invalidation issue--especially if
the browser is dealing with it in the first place. Then again, At
vendors shouldn't have to figure out everything either.
An example of this would be the functionality built-in to screen readers
to associate table headers to columns or rows in Word formatted files
which don't provide for this ability. The end-user has to identify the
items and then the screen reader can "recall" that binding. Tables are
so often encoded in HTML poorly, not including the binding of
headers/cells and AT vendors are getting increasingly good at overcoming
the problem on their own.
Allen Hoffman -- 202-447-0303
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Smith,
Sent: Monday, April 02, 2007 8:21 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Valid and well-formed code
>From a perceptive of someone making a page, why don't we use the
the would indicate what is happening when one takes a page through a
valuator. I'm still not sure if that results in valid or welformed, but
I know that making sure that a page validates properly isn't hard work.
Standard based sites to me should be norm.
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Sent: Friday, March 30, 2007 5:39 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Valid and well-formed code
We discussed the idea of adding a provision in 1194.22 on valid and
well-formed code but did not come to consensus on it.  There was some
opposition to the WCAG 2.0 wording which used the phrase "parsed
unambiguously" and was viewed to be hard to understand.
This week, the WCAG working group came up with the following more
understandable wording for this requirement:
"Web pages created using markup languages have elements with complete
start and end tags except as allowed by the specification and are nested
according to specification."
Should we add this to our draft?