WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Well formed verses Valid code

for

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

From: smithj7@peoplepc.com
Date: Fri, Feb 23 2007 8:40PM
Subject: Well formed verses Valid code
No previous message | Next message →

I saw an interesting discussion on the 508 wiki regarding the recommendation of well formed code. I really didn't understand the difference between well formed code and valid. When I take my site through a validation tool like the one provided on the w3 page, am I getting well formed code, valid code, or both? Of course I mean when I get the pass.

From: Jukka K. Korpela
Date: Sat, Feb 24 2007 12:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

On Fri, 23 Feb 2007, = EMAIL ADDRESS REMOVED = wrote:

> I really didn't understand the
> difference between well formed code and valid.

"Well-formed" is XML jargon and simply means that the data constitutes an
XML document, i.e. complies with the general syntax rules of XML. This
means rules like having a matching end tag for every start tag. For
example, <foo>bar</foo> is well-formed XML whereas <foo>bar</fox> is not.

Thus, "well-formed XML document" means the same as "XML document". The
background is that people may call their files as "XML documents" loosely,
meaning that they are meant to be XML documents and look like that, even
though they may violate the syntax rules.

"Valid" is SGML and XML jargon and means that a document, in addition to
complying with general syntax rules of SGML and XML, conforms to the
specific syntax rules defined using a particular formalism called Document
Type Definition (DTD). For more on this, check
http://www.cs.tut.fi/~jkorpela/html/validation.html

Technically, "valid HTML document" or "valid XHTML document" are
synonymous with "HTML document" and "XHTML document", since the
definitions of HTML and XHTML include a requirement on validity.

Thus, "well-formed" is relevant in XML-based contexts only, and in
describing what constitutes an XHTML document, for example, the
"well-formedness" rules are much less restrictive than "validity" rules.
"Well-formedness" operates at a low syntactic level and does not, among
other things, deal with tag and attribute names at all, except that they
contain allowable characters only.

> When I take my site
> through a validation tool like the one provided on the w3 page, am I
> getting well formed code, valid code, or both? Of course I mean when I
> get the pass.

Both, to the extent that the well-formedness concept applies (i.e., you
are using XHTML or some other XML-based language).

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: smithj7@peoplepc.com
Date: Sat, Feb 24 2007 6:00AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Thanks. What you wrote in this email really helped. I've read your article
twice and will need to return again. Your article brings me even more
questions.

In Florida, the state law says that they will follow 508. Recently one of
the larger state agencies moved from a unix envirnment to an asp envirnment.
The new pages do NOT have a DTD. They only have <html>

I feel that a DTD is important and cleaning-up codes to comply with the DTD
is a first step, to accessiblity. (work for blind services - found some
coding mistakes that cause hic-ups with speech). To me it seems like a web
site should have a DTD and that the syntax should be correct.
----- Original Message -----
From: "Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, February 24, 2007 2:31 AM
Subject: Re: [WebAIM] Well formed verses Valid code


> On Fri, 23 Feb 2007, = EMAIL ADDRESS REMOVED = wrote:
>
>> I really didn't understand the
>> difference between well formed code and valid.
>
> "Well-formed" is XML jargon and simply means that the data constitutes an
> XML document, i.e. complies with the general syntax rules of XML. This
> means rules like having a matching end tag for every start tag. For
> example, <foo>bar</foo> is well-formed XML whereas <foo>bar</fox> is not.
>
> Thus, "well-formed XML document" means the same as "XML document". The
> background is that people may call their files as "XML documents" loosely,
> meaning that they are meant to be XML documents and look like that, even
> though they may violate the syntax rules.
>
> "Valid" is SGML and XML jargon and means that a document, in addition to
> complying with general syntax rules of SGML and XML, conforms to the
> specific syntax rules defined using a particular formalism called Document
> Type Definition (DTD). For more on this, check
> http://www.cs.tut.fi/~jkorpela/html/validation.html
>
> Technically, "valid HTML document" or "valid XHTML document" are
> synonymous with "HTML document" and "XHTML document", since the
> definitions of HTML and XHTML include a requirement on validity.
>
> Thus, "well-formed" is relevant in XML-based contexts only, and in
> describing what constitutes an XHTML document, for example, the
> "well-formedness" rules are much less restrictive than "validity" rules.
> "Well-formedness" operates at a low syntactic level and does not, among
> other things, deal with tag and attribute names at all, except that they
> contain allowable characters only.
>
>> When I take my site
>> through a validation tool like the one provided on the w3 page, am I
>> getting well formed code, valid code, or both? Of course I mean when I
>> get the pass.
>
> Both, to the extent that the well-formedness concept applies (i.e., you
> are using XHTML or some other XML-based language).
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>

From: Derek Featherstone
Date: Sat, Feb 24 2007 7:10AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

On 2/24/07, = EMAIL ADDRESS REMOVED = wrote:

>I feel that a DTD is important and cleaning-up codes to comply with
>the DTD is a first step, to accessiblity. (work for blind services -
>found some coding mistakes that cause hic-ups with speech)


If ever you find errors in validation that cause issues with speech
technology such as screen readers, please please please publish the
details. Even if it is just a quick post to this list so that it gets
documented - we need to be sure that any cases or examples where this
happens are availalble for everyone to see.

Thanks!

Best regards,
Derek.
--
Derek Featherstone = EMAIL ADDRESS REMOVED =
tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca
Web Standards: http://www.webstandards.org

From: smithj7@peoplepc.com
Date: Sat, Feb 24 2007 8:10AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Will do!
----- Original Message -----
From: "Derek Featherstone" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, February 24, 2007 9:01 AM
Subject: Re: [WebAIM] Well formed verses Valid code


> On 2/24/07, = EMAIL ADDRESS REMOVED = wrote:
>
>>I feel that a DTD is important and cleaning-up codes to comply with
>>the DTD is a first step, to accessiblity. (work for blind services -
>>found some coding mistakes that cause hic-ups with speech)
>
>
> If ever you find errors in validation that cause issues with speech
> technology such as screen readers, please please please publish the
> details. Even if it is just a quick post to this list so that it gets
> documented - we need to be sure that any cases or examples where this
> happens are availalble for everyone to see.
>
> Thanks!
>
> Best regards,
> Derek.
> --
> Derek Featherstone = EMAIL ADDRESS REMOVED =
> tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America)
> Web Development: http://www.furtherahead.com
> Personal: http://www.boxofchocolates.ca
> Web Standards: http://www.webstandards.org
>

From: Alastair Campbell
Date: Mon, Feb 26 2007 2:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

> On 2/24/07, = EMAIL ADDRESS REMOVED = wrote:
>
> "I feel that a DTD is important and cleaning-up codes to comply with
> the DTD is a first step, to accessiblity."

You will certainly need one to make it easy to check the pages. If they
are using .Net there is no reason they can't use a standard doctype.
Just make sure they choose HTML 4.01 or XHTML 1, not XHTML 1.1 (which
.Net thinks it supports).

Derek Featherstone wrote:
> "If ever you find errors in validation that cause issues with speech
> technology such as screen readers, please please please publish the
> details."

It's fairly rare because they tend to cause browser issues first, but
depending on the browser I do come across things occasionally:
http://alastairc.ac/2006/06/invalid-html-interfering-with-accessibility/

I'm convinced that well-formed (X)HTML should be an accessibility (as
well as good practice) requirement, which is why I can understand why
WCAG 2 went with that phrase about pages being "parsed unambiguously",
but does anyone know if things like un-encoded ampersands could cause an
accessibility issue?

I tend to let encoding issues past (in HTML), just noting it should be
improved to ease the QA process.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Phil Teare
Date: Mon, Feb 26 2007 3:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

>
> but does anyone know if things like un-encoded ampersands could cause an
> accessibility issue?



It was an issue for Talklets. I believe it is now fully fixed. So yes it can
cause issues, BUT this is an example of where its just as easy for the AT
devs to fix it. So it should be our job, not yours. IMHO.

The biggest remaining issue in that vein is mark-up and/or code/script being
read. In order to avoid nasty effects, its often best to strip most of it.
But if its malformed (or as is usually the case, partially formed), that
will play havoc with your RegEx, and bingo its bust again (doesn't read at
all - reads very unintelligibly).

So I'd ask (as an AT developer) that Web designers avoid mixing markup and
code with 'normal' text. Please :) e.g seperate out into another container
element and lable it 'Code'.

Is this a reg already?

--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904

From: Joshue O Connor
Date: Mon, Feb 26 2007 3:50AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

>Phil said:
>It was an issue for Talklets.

Can you please expand on what happened?

> So I'd ask (as an AT developer) that Web designers avoid mixing markup and
> code with 'normal' text. Please :) e.g seperate out into another container
> element and lable it 'Code'.

Sorry Phil, just to get this straight in my head. Do you mean don't use
character encoding (in the traditional method within your document) as
it somehow conflicts with your (or any) application? Or at least, put
the character encoding in another place, outside of the flow of normal
document text?

Josh


********************************************************************

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************



From: Joshue O Connor
Date: Mon, Feb 26 2007 4:00AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

>Alastair said:
> does anyone know if things like un-encoded ampersands could cause an
> accessibility issue?

Good question. I don't think so - at least I haven't come across any in
testing - and if anyone on the list has, please post them.

Josh

********************************************************************

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************



From: Alastair Campbell
Date: Mon, Feb 26 2007 4:20AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Phil Teare wrote about unencoded ampersands:
> it can cause issues, BUT this is an example of where its just as
> easy for the AT devs to fix it. So it should be our job, not yours.

Well (from memory), the spec says to either encode the ampersands, or
use semi-colons (which very few people do), so it should be on the
authoring tool and/or server config really.

> So I'd ask (as an AT developer) that Web designers avoid
> mixing markup and
> code with 'normal' text. Please :) e.g seperate out into
> another container
> element and lable it 'Code'.

Not sure what you mean here, do you mean when people put in code
snippets to display?

Cheers,

-Alastair

From: Phil Teare
Date: Mon, Feb 26 2007 6:20AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Sorry didn't realize Josh and I had gone 'off forum' for a bit (just kept
hitting reply, thinking I was answering you too)...


> Well (from memory), the spec says to either encode the ampersands, or
> use semi-colons (which very few people do), so it should be on the
> authoring tool and/or server config really.

Agreed, but in practice, it'll be me who has the clean up after those who
don't, so I'll keep believing its up to me (and other AT devs) for the bits
I can possibly do something about...
My suggestion (and that's all it is) is that people put code snippets in a
headed div

<h3> CODE </h3>
<div>
<code>Evil marked up markup</code>
</div>

As this allows the user to avoid the code altogether, more easily
(especially if the div is styled and the user has some sight - most do).

Just: "Text you want to read <code> encoded stuff that could adjust your AT
settings or just babbel crap for 5 mins... </code> More stuff you want to
read"
, is not good. More below as to why.

Josh had asked if it was only Talklets that was effected (poss why he
politely took it off forum) and I've said no. I doubt it. Because of the
complexity of possibilities that could arise from partial code snippets and
the fact that most issues are engine dependent, not reader dependent, code
snippets even if encoded, are likely to cause issue with all AT, depending
upon which engine the user uses, its settings, the code snippet, as well as
the AT's methods of parsing and passing:

Part of my reply [slightly edited]:

> *"e.g. if any of the code snippet looks like the TTS engine's take
> on SOAP, SAMPA, IPA, or more likely its own proprietory XML based insertable
> command strings (for a section to be read faster, louder, by a different
> voice etc...), then you've got an issue. If the TTS engine has its own
> 'on/off switch' for reading XML containing strings at all, many do, and
> they're usually proprietary methods not supported by all AT, then you have a
> problem. If you strip everything XMLish, then the code will hardly be read,
> and thus not make sense. If the code is malformed and you try to strip it,
> you'll have a problem. There are tricks, like converting "<" to " angle
> braket ". But obviously this puts a stop to any hope of useing the engines
> nice XML based command string features... to issues are complex, endless and
> often impossible to entirely resolve for all TTS engines."*


Sorry if this is slightly tangential from the original issue, but does it
make sense? How would others see this better dealt with?

Cheers
Phil

Another reply I thought was to you guys too:


> Sorry. Yes, I'll clarify...
>
> When using & or &amp; or numeric Unicode representation even, the system
> had bugged in several different ways. Not reading that which came after (due
> to the system thinking the string variable to be read had finished and the
> next variable was being passed), misreading it (as 'amperes' - the most
> recent issue spotted - and fixed), etc....
>
> All of these I'm happy to call bugs, and rest on my head to solve (which I
> hope I have).
>
> However! Angle brackets, slashes,
>
> > && and ||
>
> etc... encoded or otherwise, can simply be too complex to combat. As the
> permutations are endless... Sure you can find a solution to fix any issue
> that is found, similar to the above, but in practice, not every.
>
> So if you are putting code or markup on a page (obviously most of the time
> you'd have to encode this, as otherwise it'd be rendered), the best thing to
> do IMO would be to put it in its own container (most likely a div). That
> way, if it messes with the AT, at least you can read the rest of the page/
> adjoining elements and you'll know why it may being reading badly, or not at
> all (because it'll be headed 'Code').
>
> So... For small common instances of special character (e.g. &) just encode
> them and use them as you wish, and we (the AT Devs) will try to cope. BUT if
> you're marking up markup or script (which you'll prob have to encode anyway)
> please stick it in a div and label it code (as is often the case on BBs and
> such anyway). I'm sure this could be refined, but its better than nothing.
>
>
> Is that clearer? Hopes so.
>

--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904

From: Derek Featherstone
Date: Mon, Feb 26 2007 7:20AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

On 2/26/07, Alastair Campbell wrote:

>Derek Featherstone wrote:
>> "If ever you find errors in validation that cause issues with speech
>> technology such as screen readers, please please please publish the
>> details."
>
>It's fairly rare because they tend to cause browser issues first, but
>depending on the browser I do come across things occasionally:
>http://alastairc.ac/2006/06/invalid-html-interfering-with-accessibility

Hi Alastair - thanks for that link, and yes, I'm asking people to
publish anything that they find because the issues are rare.

>does anyone know if things like un-encoded ampersands could cause an
>accessibility issue?

Way back in the dark ages (i.e., 1999-2000) an app at the college where
I was consulting was causing all kinds of strife because of unencoded
ampersands in URLs. I don't remember all the details, but the bottom
line was that one of the GET params was converted to the character
entity (the URL was /whatever.asp?term=2000W&crs=501&section=1) and the
&section was getting converted to the &sect; (the ; is optional so it
interpreted it as such without the encoded ampersand) entity which meant
data wasn't being saved properly and what was shown back to the user on
their confirmation page wasn't what was expected and wasn't saved
properly. Stretching it, I know, but it was the only case I have ever
seen where an unencoded ampersand caused a real problem. Not strictly
accessibility, either, and certainly not discriminatory based on ability
- it affected everyone equally, as all were confused!


Cheers,
Derek.
--
Derek Featherstone = EMAIL ADDRESS REMOVED =
tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America)
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca
Web Standards: http://www.webstandards.org

From: Alastair Campbell
Date: Mon, Feb 26 2007 7:30AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Phil Teare wrote:
> if you're marking up markup or script (which you'll prob have
> to encode anyway) please stick it in a div and label it code

Surely the author/CMS should put the snippet in a pre and/or code?

I tend to use this for blocks of code:

<pre><code>
[code here]
</code></pre>

And just a code element for inline bits. Anything in a pre, code, var,
kbd etc. could justifiably have a different rendering, audio or
otherwise.

I guess the hard part is authors who don't encode their content
snippets? In which case uuencoded ampersands would cause issues,
although perhaps not when in an attribute such as href?

> e.g. if any of the code snippet looks like the TTS engine's take
> on SOAP, SAMPA, IPA, or more likely its own proprietory XML based
insertable
> command strings (for a section to be read faster, louder, by a
different
> voice etc...),

Are certain UAs are looking for their own custom XML snippets in the
page? Surely that would encouraging inline, agent-specific styling/code?

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Phil Teare
Date: Mon, Feb 26 2007 8:10AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

>
> Surely the author/CMS should put the snippet in a pre and/or code?
>

Got to admit, pre was new to me (I really don't know everything...), but my
thought is that containing in a div and 'warning' the reader is a good plan
to help the user avoid running into code. Even if the AT has a setting to
not read <code> elements, the chances are the user doesn't know where that
setting is, and even if its encoded.


> And just a code element for inline bits. Anything in a pre, code, var,
> kbd etc. could justifiably have a different rendering, audio or
> otherwise.

Yes but the user wouldn't get as much warning. Its an entirely subjective
design issue that I'm putting forward, but I think its fair (airing now, in
part to see if you and others agree though)...

I guess the hard part is authors who don't encode their content
> snippets?


Unfortunately not. Like I say the TTS engine (which is not under the
assistive technology's control developmently speaking, and often not
entirely programmatically speaking) is too often the cause for concern. Even
with encoding. Especially as the AT may decode it to read it (bepending on
text format issues).


> In which case uuencoded ampersands would cause issues,
> although perhaps not when in an attribute such as href?


Not quite so much as they are 'simple' and common. So its easier to program
around any issues. Unlike 'CODE' which is infinitely complex in its possible
form and effect... So I feel loathed to accept responsibility for trying to
get it read perfectly every time...

> e.g. if any of the code snippet looks like the TTS engine's take
> on SOAP, SAMPA, IPA, or more likely its own proprietory XML based
insertable
> command strings (for a section to be read faster, louder, by a
different
> voice etc...),

Are certain UAs are looking for their own custom XML snippets in the
> page? Surely that would encouraging inline, agent-specific styling/code?


Some text to speech engines are. I'm sure you're aware, but incase you're
not:

The assistive techs (JAWS, Talklets, Opera, Eyes, etc...), be they the
browser, some script and a plugin, an independent installed app connecting
to the DOM via the OS or UA's API,... all use TTS engines which are not
theirs. Moreover, could be anyones. e.g. you can use L&H voices, or AT&T or
Nuance, or Elan, or.... on any of the ATs affore mentioned. Most of these
will receive and act upon command strings. These strings are often XML-like
(hense to risk of inadvertantly triggering commands/re-parsing badly or not
reading at all due to little known settings). Unsuprisingly, there are more
standards re these embeddable command strings than engines!!! Many
proprietory, but just as many not.

While its unlikely the VoicXML enabled engines will be caused issues due to
the AT passing it malformed code, other embedded string command protocols
are more easily confused/accidentally triggered...

So unlike most folks take on accessiblity, we're not just in a mess of Web
developers who care, Web Developers who don't, Assistive Tech developers,
Web Standards and User Agents - the text to speech engines themselves are
also in the mix of 'Things to Worry About' when pages contain special
charecters and 'code'...

:(

Phil


--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904

From: Andrew Kirkpatrick
Date: Mon, Feb 26 2007 8:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

> >It's fairly rare because they tend to cause browser issues
> first, but
> >depending on the browser I do come across things occasionally:
> >http://alastairc.ac/2006/06/invalid-html-interfering-with-acc
essibility
>
> Hi Alastair - thanks for that link, and yes, I'm asking
> people to publish anything that they find because the issues
> are rare.

Alastair, How do you differentiate between invalid html interfering with
accessibility and interfering with proper functioning? The example you
show is interpreted in different browsers differently, but not just when
assistive technology is in operation. This issue affects potentially
all users with javascript off, not just disabled users.

I'll agree that the invalid code shown makes consistent rendering less
likely in this instance, but I'm not sure that I'd call it an
accessibility issue - just an issue.

Valid code is worth doing for many reasons, but I'm still waiting for an
example that shows me that invalid code creates problems that
discriminates singularly against disabled users. For this reason, I'm in
favor of accessibility standards that address issues that affect users,
but not for a standard requiring valid code.

AWK

From: Alastair Campbell
Date: Mon, Feb 26 2007 9:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Andrew Kirkpatrick wrote:
> Alastair, How do you differentiate between invalid html
> interfering with accessibility and interfering with proper
functioning?

Hi Andrew,

This came up in the context of a accessibility audit against WCAG 1, so
checkpoints for JavaScript and valid HTML applied.

> The example you show is interpreted in different browsers
differently,
> but not just when assistive technology is in operation. This issue
affects
> potentially all users with JavaScript off, not just disabled users.

Quite right, it is definitely one that I would consider potentially an
issue to many, regardless of ability. This one is about correct use of
the HTML standard so that any UA (should) be able to render it properly.

In practice, I would consider it something that should be caught in
general QA, rather than something that will affect people with
disabilities in particular.

> I'll agree that the invalid code shown makes consistent rendering less
> likely in this instance, but I'm not sure that I'd call it an
> accessibility issue - just an issue.

I suppose you could argue that people with disabilities are more likely
to be using an alternative user-agent, but I wouldn't try very hard on
that one!

This might be of interest:
http://blog.fawny.org/2004/05/13/screen-reader-code/

> I'm in favor of accessibility standards that address issues that
> affect users, but not for a standard requiring valid code.

I know what you mean, but I've been quite glad of the accessibility
carrot/stick including valid HTML. It has improved the quality and
interoperability of several projects I've been involved with which would
have disregarded it otherwise.

If they are using CSS for layout, it's generally a necessary step to use
valid HTML, but otherwise it's very hard to eject the tag-soup habits.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Andrew Kirkpatrick
Date: Mon, Feb 26 2007 12:00PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

> This might be of interest:
> http://blog.fawny.org/2004/05/13/screen-reader-code/

This ignores the fact that the two screen readers that are referenced in
this post don't parse the HTML themselves - they use MSAA or the DOM to
get their interpretation of the content. The question beomes whether
the browsers make errors in their interpretation of the HTML and
subsequent creation of the DOM or MSAA tree, not whether screen readers
prefer valid code or not.

AWK

From: Joshue O Connor
Date: Mon, Feb 26 2007 12:20PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

In the http://blog.fawny.org/ post on the 'Influence of valid code on
screen readers':

>>Joe Clark says:

>[Product 1] does tend to behave better with valid code because the
browser behaves better with valid code. Take, for example, tables.
>Invalid table code may cause tables to be rendered incorrectly, thereby
causing [Product 1] to read them incorrectly.

Nice.

However, in order to figure out this willfully obscure posting are we
supposed to play guess the user agent, starring our special guest
mystery user agent <lights><drumroll> [insert random ambiguous
initialism starting with a J or W E, or maybe even an S or a
H']</lights></drumroll>??

Josh



********************************************************************

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************



From: Alastair Campbell
Date: Mon, Feb 26 2007 2:00PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

> the two screen readers that are referenced in
> this post don't parse the HTML themselves - they use MSAA or
> the DOM to get their interpretation of the content.

I believe older versions of JAWs parsed the HTML independently of the
browser, something that has changed since version 7.1.

Wouldn't there be a potential for different processing by the screen
readers compared to the browsers? Especially for non-valid or not well
formed markup.

Ian Hickson produced a tool to evaluate the DOM trees (probably
available from here but I can't access it right now:
http://www.hixie.ch/tests/adhoc/html/parsing/compat/viewer.html)

I'm not sure whether that would work for checking screen readers, but it
might be necessary to use something like that to test for differences.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Robinson, Norman B - Washington, DC
Date: Mon, Feb 26 2007 2:10PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

I'll chime in with some generalizations for all our 1+ million
or so internal pages at USPS.

Valid DTD's should be required by policy.

Before anyone can begin to determine what does or does not work,
you have to account for a variety of factors, including which screen
reader you are using, on which operating system, and which version is in
use. Rather than show specific examples to allow the reader to logically
find faults or assign validation versus accessibility issues, let me
offer you a scenario.

If the screen reader software itself is software and thus
subject to defects, interprets HTML markup (via the DOM or by accessing
the code) and you encounter a defect, is it the content or the screen
reader? We can point to "invalid code" or "code that will not pass
automated validation" that is accessible. That doesn't mean that the
screen reader _should_ be expected to make the content accessible. That
is, if the screen reader were to follow the HTML standards, we might
logically forgive the software for not providing access if the *code or
content* didn't follow the standards that exist. Part of establishing
that the content is standard is defining the DTD. This also brings
awareness to the content creator about DTD and a standards based
approach.

Add to that there is no "one browser". Just as in screen readers
themselves, multiple versions of browsers exist, all providing multiple
levels of quality to MSAA or DOM information, thus also impacting the
screen readers that relies on that information. Personally, I've
experienced the most issues with nested tables; issues where the screen
reader couldn't access the content where it was clear the table wasn't
coded correctly and it impacted accessibility. My point is, if there is
a standard and a way to validate you meet that standard, why would you
_NOT_ want to try and validate?

This isn't about whether software prefers valid code or not. It
is ultimately better if we follow a standards based approach so that
when we do find defects in (HTML) code or content, we can expect the
vendor to solve the defect. We wouldn't be able to do that with
non-validating code to any reasonable degree. Also, when we do validate
we reduce defects and errors, improving the general "quality" of our
code. We verify we coded correctly or the tools we used created valid
code, which is an indication of quality you cannot assume if you don't
test or validate.

Short version: Ensure you validate your code and you'll increase
your quality, increasing the ultimate likelihood for accessibility in
the process.

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246




-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Monday, February 26, 2007 1:43 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Well formed verses Valid code


> This might be of interest:
> http://blog.fawny.org/2004/05/13/screen-reader-code/

This ignores the fact that the two screen readers that are referenced in
this post don't parse the HTML themselves - they use MSAA or the DOM to
get their interpretation of the content. The question beomes whether
the browsers make errors in their interpretation of the HTML and
subsequent creation of the DOM or MSAA tree, not whether screen readers
prefer valid code or not.

AWK

From: Andrew Kirkpatrick
Date: Mon, Feb 26 2007 2:30PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

I'll agree that valid code has benefits for the developer, including
ones you mention. I'll support it in a corporate or agency policy for
web development, but for reasons apart from accessibility. Validity
tests may find some issues that affect accessibility, but these issues
are covered elsewhere in accessibility standards (e.g. missing alt
attribute on an image). I have yet to see an issue where the code is so
mangled that it impacts the way assistive technologies render the
content but that doesn't affect the visual rendering for sighted users.
I agree that valid code should be a policy, just not an accessibility
policy.

AWK


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Monday, February 26, 2007 4:00 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Well formed verses Valid code
>
>
> I'll chime in with some generalizations for all our 1+
> million or so internal pages at USPS.
>
> Valid DTD's should be required by policy.
>
> Before anyone can begin to determine what does or does
> not work, you have to account for a variety of factors,
> including which screen reader you are using, on which
> operating system, and which version is in use. Rather than
> show specific examples to allow the reader to logically find
> faults or assign validation versus accessibility issues, let
> me offer you a scenario.
>
> If the screen reader software itself is software and
> thus subject to defects, interprets HTML markup (via the DOM
> or by accessing the code) and you encounter a defect, is it
> the content or the screen reader? We can point to "invalid
> code" or "code that will not pass automated validation" that
> is accessible. That doesn't mean that the screen reader
> _should_ be expected to make the content accessible. That is,
> if the screen reader were to follow the HTML standards, we
> might logically forgive the software for not providing access
> if the *code or
> content* didn't follow the standards that exist. Part of
> establishing that the content is standard is defining the
> DTD. This also brings awareness to the content creator about
> DTD and a standards based approach.
>
> Add to that there is no "one browser". Just as in
> screen readers themselves, multiple versions of browsers
> exist, all providing multiple levels of quality to MSAA or
> DOM information, thus also impacting the screen readers that
> relies on that information. Personally, I've experienced the
> most issues with nested tables; issues where the screen
> reader couldn't access the content where it was clear the
> table wasn't coded correctly and it impacted accessibility.
> My point is, if there is a standard and a way to validate you
> meet that standard, why would you _NOT_ want to try and validate?
>
> This isn't about whether software prefers valid code or
> not. It is ultimately better if we follow a standards based
> approach so that when we do find defects in (HTML) code or
> content, we can expect the vendor to solve the defect. We
> wouldn't be able to do that with non-validating code to any
> reasonable degree. Also, when we do validate we reduce
> defects and errors, improving the general "quality" of our
> code. We verify we coded correctly or the tools we used
> created valid code, which is an indication of quality you
> cannot assume if you don't test or validate.
>
> Short version: Ensure you validate your code and you'll
> increase your quality, increasing the ultimate likelihood for
> accessibility in the process.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Monday, February 26, 2007 1:43 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Well formed verses Valid code
>
>
> > This might be of interest:
> > http://blog.fawny.org/2004/05/13/screen-reader-code/
>
> This ignores the fact that the two screen readers that are
> referenced in this post don't parse the HTML themselves -
> they use MSAA or the DOM to get their interpretation of the
> content. The question beomes whether the browsers make
> errors in their interpretation of the HTML and subsequent
> creation of the DOM or MSAA tree, not whether screen readers
> prefer valid code or not.
>
> AWK
>

From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Feb 26 2007 3:30PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Andrew Kirkpatrick wrote:
> I have yet to see an issue where
> the code is so mangled that it impacts the way assistive technologies
> render the content but that doesn't affect the visual rendering for
> sighted users. I agree that valid code should be a policy, just not
> an accessibility policy.
>
> AWK
>

Some thoughts:

1. Universal Accessibility should be (is!) about more than just adaptive
technologies (Past, Present or Future) - I always thought the goal was that
our content would render for *all* technologies - we're not building cars
for the information highway, we're supplying the fuel. You can drive any
vehicle you want, but the fuel I dispense will always be "pure" (valid).
Valid code, as Norman Robinson pointed out, returns the responsibility to
the user agents to process the information correctly to the end user - and
this includes but is not limited to Adaptive Technology (which can assist
users who do not fall into the "sighted" or "not-sighted" category). I've
seen code that rendered fine on screen, that read fine to screen readers,
but was functionally "broken" simply due to invalid code (I'm thinking of
some .net crap that only works in IE browsers - I have no current or
specific examples). If we (or at least I) keep talking about Universal
Accessibility, but continually return back to Adaptive Technology "quirks"
(or lack of), it somehow dilutes the message to me. It's almost a reverse
discrimination.

2. Accessibility should be part of "The Policy" (full stop). That same
policy should also include requirements for valid code, and can include
other requirements as well - I spent a fair bit of time working within the
Canadian Government's Common Look and Feel policy, which included
accessibility, but spoke to much more, including the fact that Canada is an
officially bilingual country (along with all that this entails), and other
related items (email auto-responders for example - their usage, structure,
etc.). I am troubled that we again want to marginalize "accessibility" and
speak about specifics regarding Adaptive Technology - yet at the same time
we preach that Universal Accessibility is foundational, and not something
that you bolt on at the end of the day.

Which is it?

Just my $0.02

JF


From: Loretta Guarino Reid
Date: Mon, Feb 26 2007 3:40PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Hi, John,

I must admit, I am surprised to see your strict call for validity
within a week of seeing your ardent defence of the (mis)use of the
title attribute of the abbr element for Microformat data.

Loretta

On 2/26/07, John Foliot - Stanford Online Accessibility Program
< = EMAIL ADDRESS REMOVED = > wrote:
> Andrew Kirkpatrick wrote:
> > I have yet to see an issue where
> > the code is so mangled that it impacts the way assistive technologies
> > render the content but that doesn't affect the visual rendering for
> > sighted users. I agree that valid code should be a policy, just not
> > an accessibility policy.
> >
> > AWK
> >
>
> Some thoughts:
>
> 1. Universal Accessibility should be (is!) about more than just adaptive
> technologies (Past, Present or Future) - I always thought the goal was that
> our content would render for *all* technologies - we're not building cars
> for the information highway, we're supplying the fuel. You can drive any
> vehicle you want, but the fuel I dispense will always be "pure" (valid).
> Valid code, as Norman Robinson pointed out, returns the responsibility to
> the user agents to process the information correctly to the end user - and
> this includes but is not limited to Adaptive Technology (which can assist
> users who do not fall into the "sighted" or "not-sighted" category). I've
> seen code that rendered fine on screen, that read fine to screen readers,
> but was functionally "broken" simply due to invalid code (I'm thinking of
> some .net crap that only works in IE browsers - I have no current or
> specific examples). If we (or at least I) keep talking about Universal
> Accessibility, but continually return back to Adaptive Technology "quirks"
> (or lack of), it somehow dilutes the message to me. It's almost a reverse
> discrimination.
>
> 2. Accessibility should be part of "The Policy" (full stop). That same
> policy should also include requirements for valid code, and can include
> other requirements as well - I spent a fair bit of time working within the
> Canadian Government's Common Look and Feel policy, which included
> accessibility, but spoke to much more, including the fact that Canada is an
> officially bilingual country (along with all that this entails), and other
> related items (email auto-responders for example - their usage, structure,
> etc.). I am troubled that we again want to marginalize "accessibility" and
> speak about specifics regarding Adaptive Technology - yet at the same time
> we preach that Universal Accessibility is foundational, and not something
> that you bolt on at the end of the day.
>
> Which is it?
>
> Just my $0.02
>
> JF
>
>
>

From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Feb 26 2007 3:50PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Loretta Guarino Reid wrote:
> Hi, John,
>
> I must admit, I am surprised to see your strict call for validity
> within a week of seeing your ardent defence of the (mis)use of the
> title attribute of the abbr element for Microformat data.
>
> Loretta
>

LOL

However, while microformats may be using the title attribute "creatively",
(some may say incorrectly, but I don't 100% agree with that opinion), it
does not render the document invalid - on the contrary, perhaps *because*
the microformats community wants to adhere to standards (and valid code)
they are using a valid attribute in a way not originally envisioned but, I
must point out, not restricted nor forbidden by the W3C specs:

"title = text [CS] This attribute offers advisory information about
the element for which it is set. Values of the title attribute may be
rendered by user agents in a variety of ways."

Cheers!

JF


From: smithj7@peoplepc.com
Date: Mon, Feb 26 2007 5:50PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Unfortunately, in Florida, it seems like folks don't want to do simple stuff
like have dtd. That's why I want to know if well formed is enough. Can you
even tell if code is well formed without a doc type?

Our agency uses dreamweaver and it will validate code. I also check with
the w3 validator. I just don't know if I'm getting valid code or well
formed when I take it through one of these.
----- Original Message -----
From: "Robinson, Norman B - Washington, DC" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, February 26, 2007 4:00 PM
Subject: Re: [WebAIM] Well formed verses Valid code


>
> I'll chime in with some generalizations for all our 1+ million
> or so internal pages at USPS.
>
> Valid DTD's should be required by policy.
>
> Before anyone can begin to determine what does or does not work,
> you have to account for a variety of factors, including which screen
> reader you are using, on which operating system, and which version is in
> use. Rather than show specific examples to allow the reader to logically
> find faults or assign validation versus accessibility issues, let me
> offer you a scenario.
>
> If the screen reader software itself is software and thus
> subject to defects, interprets HTML markup (via the DOM or by accessing
> the code) and you encounter a defect, is it the content or the screen
> reader? We can point to "invalid code" or "code that will not pass
> automated validation" that is accessible. That doesn't mean that the
> screen reader _should_ be expected to make the content accessible. That
> is, if the screen reader were to follow the HTML standards, we might
> logically forgive the software for not providing access if the *code or
> content* didn't follow the standards that exist. Part of establishing
> that the content is standard is defining the DTD. This also brings
> awareness to the content creator about DTD and a standards based
> approach.
>
> Add to that there is no "one browser". Just as in screen readers
> themselves, multiple versions of browsers exist, all providing multiple
> levels of quality to MSAA or DOM information, thus also impacting the
> screen readers that relies on that information. Personally, I've
> experienced the most issues with nested tables; issues where the screen
> reader couldn't access the content where it was clear the table wasn't
> coded correctly and it impacted accessibility. My point is, if there is
> a standard and a way to validate you meet that standard, why would you
> _NOT_ want to try and validate?
>
> This isn't about whether software prefers valid code or not. It
> is ultimately better if we follow a standards based approach so that
> when we do find defects in (HTML) code or content, we can expect the
> vendor to solve the defect. We wouldn't be able to do that with
> non-validating code to any reasonable degree. Also, when we do validate
> we reduce defects and errors, improving the general "quality" of our
> code. We verify we coded correctly or the tools we used created valid
> code, which is an indication of quality you cannot assume if you don't
> test or validate.
>
> Short version: Ensure you validate your code and you'll increase
> your quality, increasing the ultimate likelihood for accessibility in
> the process.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
> Kirkpatrick
> Sent: Monday, February 26, 2007 1:43 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Well formed verses Valid code
>
>
>> This might be of interest:
>> http://blog.fawny.org/2004/05/13/screen-reader-code/
>
> This ignores the fact that the two screen readers that are referenced in
> this post don't parse the HTML themselves - they use MSAA or the DOM to
> get their interpretation of the content. The question beomes whether
> the browsers make errors in their interpretation of the HTML and
> subsequent creation of the DOM or MSAA tree, not whether screen readers
> prefer valid code or not.
>
> AWK
>

From: smithj7@peoplepc.com
Date: Mon, Feb 26 2007 6:00PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Good points. I went to the Web Master Jam Session 2006 which included
mostly private sector folks. Standard based coding was a theme that went
through out the program. I went back, worked on a style sheet for "front
page" and secondary pages, and discovered I did need to clean my code to
make the css style sheet work. I'm almost through cleaning up all the
folders and will be able to put up the new page (looks like old one, but is
now standard based - if I understood the term as it was used). I don't
understand why we all won't want to start with basic good (x)html, xml, css
standards and then work on accessiblity. Wouldn't it even be wonderful if
we had standards for (x)html, xml, css that included accessiblity issues as
part of those standards, kind of what the new building codes have, if I
understand how the new building codes work.

----- Original Message -----
From: "John Foliot - Stanford Online Accessibility Program"
< = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, February 26, 2007 5:27 PM
Subject: Re: [WebAIM] Well formed verses Valid code


> Andrew Kirkpatrick wrote:
>> I have yet to see an issue where
>> the code is so mangled that it impacts the way assistive technologies
>> render the content but that doesn't affect the visual rendering for
>> sighted users. I agree that valid code should be a policy, just not
>> an accessibility policy.
>>
>> AWK
>>
>
> Some thoughts:
>
> 1. Universal Accessibility should be (is!) about more than just adaptive
> technologies (Past, Present or Future) - I always thought the goal was
> that
> our content would render for *all* technologies - we're not building cars
> for the information highway, we're supplying the fuel. You can drive any
> vehicle you want, but the fuel I dispense will always be "pure" (valid).
> Valid code, as Norman Robinson pointed out, returns the responsibility to
> the user agents to process the information correctly to the end user - and
> this includes but is not limited to Adaptive Technology (which can assist
> users who do not fall into the "sighted" or "not-sighted" category). I've
> seen code that rendered fine on screen, that read fine to screen readers,
> but was functionally "broken" simply due to invalid code (I'm thinking of
> some .net crap that only works in IE browsers - I have no current or
> specific examples). If we (or at least I) keep talking about Universal
> Accessibility, but continually return back to Adaptive Technology "quirks"
> (or lack of), it somehow dilutes the message to me. It's almost a reverse
> discrimination.
>
> 2. Accessibility should be part of "The Policy" (full stop). That same
> policy should also include requirements for valid code, and can include
> other requirements as well - I spent a fair bit of time working within the
> Canadian Government's Common Look and Feel policy, which included
> accessibility, but spoke to much more, including the fact that Canada is
> an
> officially bilingual country (along with all that this entails), and other
> related items (email auto-responders for example - their usage, structure,
> etc.). I am troubled that we again want to marginalize "accessibility"
> and
> speak about specifics regarding Adaptive Technology - yet at the same time
> we preach that Universal Accessibility is foundational, and not something
> that you bolt on at the end of the day.
>
> Which is it?
>
> Just my $0.02
>
> JF
>
>
>

From: Andrew Kirkpatrick
Date: Mon, Feb 26 2007 9:10PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

John,

> information highway, we're supplying the fuel. You can drive
> any vehicle you want, but the fuel I dispense will always be
> "pure" (valid).

Car engines, like browsers, are forgiving of impurities to a certain
extent. You can argue that cars would get better mileage if all fuel
was 100% pure, but the reality in the way that fuel is produced that
this is not always practical.

> I've
> seen code that rendered fine on screen, that read fine to
> screen readers, but was functionally "broken" simply due to
> invalid code (I'm thinking of some .net crap that only works

Maybe I'm missing something - it worked for AT and looked fine, but was
broken functionally?

> 2. Accessibility should be part of "The Policy" (full stop).

Of course.

> I am troubled that
> we again want to marginalize "accessibility" and speak about
> specifics regarding Adaptive Technology - yet at the same
> time we preach that Universal Accessibility is foundational,
> and not something that you bolt on at the end of the day.

I'm not sure which 'we' you're talking about. I'm not advocating any
interest in marginalizing accessibility. All that I'm stating is that
validity does not equal accessibility. You can take a perfectly valid
and accessible page and make a minor change (un-encode an ampersand in a
parameter string or use <b> instead of <strong> in an XHTML strict
document) -- is the page going to be less accessible? Keep making
changes and you will eventually affect the visual appearance and also
the experience for keyboard or screen reader or other AT users, but
those are the issues that we need to address and have easy to follow
guidelines for. There is just too much extra stuff that validity covers
that doesn't affect accessibility for actual users.

My responses are largely in response to Alastair's "I'm convinced that
well-formed (X)HTML should be an accessibility (as well as good
practice) requirement" statement. I'm not convinced that it should be
an accessibility requirement, but I am convinced that a robust
development process will address validity issues for other reasons.

AWK

From: Alastair Campbell
Date: Tue, Feb 27 2007 2:40AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Andrew Kirkpatrick wrote:
> My responses are largely in response to Alastair's "I'm convinced that
> well-formed (X)HTML should be an accessibility (as well as good
> practice) requirement" statement. I'm not convinced that it should be
> an accessibility requirement, but I am convinced that a robust
> development process will address validity issues for other reasons.

I'm sorry I don't have an example of an issue to hand, but isn't it a
logical extension of the reasoning for valid code? I'm preaching to the
choir here, but guess I need to, to work out where our reasoning
differs:

We use valid code to be sure that various user agents render the content
as expected. (Of course they don't in practice, but at least then we
know it's a bug of that user agent and therefore their responsibility.)

Visual rendering issues in common browsers will be caught because people
generally include a cross-browser checks as part of the development
process.

Those cross-browser checks are with a limited set of browsers (e.g.
http://developer.yahoo.com/yui/articles/gbs/index.html). Therefore a
normal development process does not include all browsers, let alone all
assistive technologies.

Since each of these assistive technologies could render non-valid code
differently, the best thing you can do within a reasonable effort is
ensure that you use valid code, and check common user agents.

It may be that an ampersand in an href is not going to affect any known
user agent, but if you're going to provide a guide for developers, I'd
keep it simple: use valid code. I have been in situations where
developers were reluctant to use valid code because it meant changing
their CMS, so I don't think it will necessarily be caught by other parts
of the process.

If HTML5 uses a schema rather than DTD based method for checking, that's
fine to (and I believe goes some way to addressing your concern), but in
the mean time, I'll keep pointing people to the W3C validator.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Joshue O Connor
Date: Tue, Feb 27 2007 6:10AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

This has been a really interesting thread, with good points being raised
by both sides (??)

> It may be that an ampersand in an href is not going to affect any known
> user agent, but if you're going to provide a guide for developers, I'd
> keep it simple: use valid code.

I'd buy that. Validity may not be 100% exclusively an accessibility
issue but in terms of the advice I would give developers it is..(if that
makes sense) ;)

Josh

********************************************************************

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************



From: Roberto Modica
Date: Tue, Feb 27 2007 7:50AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

I would agree with that Josh. Ensuring your code is valid should be the
first thing developers do and that's what I try and enforce with my
developers.

Rob

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Joshue O Connor
Sent: 27 February 2007 13:05
To: WebAIM Discussion List
Subject: Re: [WebAIM] Well formed verses Valid code

This has been a really interesting thread, with good points being raised
by both sides (??)

> It may be that an ampersand in an href is not going to affect any known
> user agent, but if you're going to provide a guide for developers, I'd
> keep it simple: use valid code.

I'd buy that. Validity may not be 100% exclusively an accessibility
issue but in terms of the advice I would give developers it is..(if that
makes sense) ;)

Josh

********************************************************************

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************

From: John Foliot - Stanford Online Accessibility Program
Date: Tue, Feb 27 2007 11:20AM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

Alastair Campbell wrote:

...a response I totally agree with. He said:

>
> We use valid code to be sure that various user agents render the
> content as expected. (Of course they don't in practice, but at least
> then we know it's a bug of that user agent and therefore their
> responsibility.)

(Pure petrol/gasoline vs. flawed autos)

>
> Since each of these assistive technologies could render non-valid
> code differently, the best thing you can do within a reasonable
> effort is ensure that you use valid code, and check common user
> agents.

I might also add that in the subjective realm of applying the WCAG against
your content (What *is* an appropriate ALT text? - we believe we know what
is *not* appropriate, but everything else is opinion; what is "blink"
exactly?) ensuring valid code is a binary check - it's valid or it's not.
When instructing or teaching new students to the concepts of accessible web
development, it's nice to have a solid foundation to build upon, and that
foundation is code standards.

Andrew, this is not a criticism aimed at or to you, but I am at a total loss
as to why so many developers dismiss valid (x)HTML as a non-issue, or not
critical to the accessible development process. Andrew may be right that in
practical terms, many pages that do not validate are still accessible to
mainstream users as well as the majority of users of AT. Does this then
make it right? I argue no - if it fails one person due to "bad code", then
we as developers have failed.

Setting valid code as a requirement for "accessibility" establishes the fact
that developers must take care, must think through what they are doing, and
must not rely on hacks, cheats, and trickery to appease one browser or the
other - a situation that is not as prevalent as it was 5 years ago, but
still persists. Forgiving large CMSes and other large-scale
platforms/developments for what should be trivial things to fix in essence
says "Do your best, but don't worry too much, it's not really that
important" - and if getting a basic markup language syntax correct is not
that important, why should other arcane requirements such as providing a
long description, or captioning to videos be any more important - hey.. They
tried their best, but Oops... Sorry. It's a mind set thing.

To the seasoned veterans of this list (and others) who have been banging
away at this for years, Andrew's points can have some credence - I simply
worry that the message it sends to the uninitiated or newer developers who
are beginning this journey may be confusing. Validation is simple, and
keeping things simple for beginners is not a bad thing - once you can
produce valid code all the time, every time, regardless of whether the pages
are hand coded in notepad, or churned out by a CMS, blogging tool or other
means, then you can relax your requirements slightly. Once you understand
the "rules", then when you break a rule, you know a) that you have, b) you
know why, and c) you have a good idea of the potential for problems it may
or may not be creating. But before you get there, striving for and
attaining code validation is a good start. I know that Andrew does not
disagree with the need/desire for valid code - that's not what he has said.
But I think that de-linking code validation from accessible web development
is the edge or a slippery slope, it in effect says that standards can be
secondary to results - a point that flies in the face of logic to me.

>
> It may be that an ampersand in an href is not going to affect any
> known user agent, but if you're going to provide a guide for
> developers, I'd keep it simple: use valid code.

EXCEPT... Earlier in this thread my good friend Derek Featherstone pointed
out a situation (rare, but real) where a fouled ampersand *DID* negatively
affect the outcome (http://webaim.org/discussion/mail_message.php?id=10177).

> I have been in
> situations where developers were reluctant to use valid code because
> it meant changing their CMS, so I don't think it will necessarily be
> caught by other parts of the process.

And see, that's the point. If they are reluctant to something as basic as
code validation, and it is accepted that this is OK, then what happens when
they must do something else in the name of accessibility?

JF


From: Roberto Modica
Date: Tue, Feb 27 2007 2:40PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

I believe that validating code is our first step to any sort of quality
assurance that we have when developing websites. From an accessibility
point of view I feel that it is important that new and old developers
validate there code as the starting point of accessibility, ensuring that no
invalid mark-up has any chance of affecting accessibility in any way. The
process is simple and should be part of any developers' workflow, and I
don't believe that validating your pages add significant amount of time to
the development process and should be carried out. If someone is using a
'non-conventional' browser then the potential is there for non-compliance if
validation fails, if we are in control of that then it is something we
should do.

Rob

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of John Foliot -
Stanford Online Accessibility Program
Sent: 27 February 2007 18:19
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Well formed verses Valid code

Alastair Campbell wrote:

...a response I totally agree with. He said:

>
> We use valid code to be sure that various user agents render the
> content as expected. (Of course they don't in practice, but at least
> then we know it's a bug of that user agent and therefore their
> responsibility.)

(Pure petrol/gasoline vs. flawed autos)

>
> Since each of these assistive technologies could render non-valid
> code differently, the best thing you can do within a reasonable
> effort is ensure that you use valid code, and check common user
> agents.

I might also add that in the subjective realm of applying the WCAG against
your content (What *is* an appropriate ALT text? - we believe we know what
is *not* appropriate, but everything else is opinion; what is "blink"
exactly?) ensuring valid code is a binary check - it's valid or it's not.
When instructing or teaching new students to the concepts of accessible web
development, it's nice to have a solid foundation to build upon, and that
foundation is code standards.

Andrew, this is not a criticism aimed at or to you, but I am at a total loss
as to why so many developers dismiss valid (x)HTML as a non-issue, or not
critical to the accessible development process. Andrew may be right that in
practical terms, many pages that do not validate are still accessible to
mainstream users as well as the majority of users of AT. Does this then
make it right? I argue no - if it fails one person due to "bad code", then
we as developers have failed.

Setting valid code as a requirement for "accessibility" establishes the fact
that developers must take care, must think through what they are doing, and
must not rely on hacks, cheats, and trickery to appease one browser or the
other - a situation that is not as prevalent as it was 5 years ago, but
still persists. Forgiving large CMSes and other large-scale
platforms/developments for what should be trivial things to fix in essence
says "Do your best, but don't worry too much, it's not really that
important" - and if getting a basic markup language syntax correct is not
that important, why should other arcane requirements such as providing a
long description, or captioning to videos be any more important - hey.. They
tried their best, but Oops... Sorry. It's a mind set thing.

To the seasoned veterans of this list (and others) who have been banging
away at this for years, Andrew's points can have some credence - I simply
worry that the message it sends to the uninitiated or newer developers who
are beginning this journey may be confusing. Validation is simple, and
keeping things simple for beginners is not a bad thing - once you can
produce valid code all the time, every time, regardless of whether the pages
are hand coded in notepad, or churned out by a CMS, blogging tool or other
means, then you can relax your requirements slightly. Once you understand
the "rules", then when you break a rule, you know a) that you have, b) you
know why, and c) you have a good idea of the potential for problems it may
or may not be creating. But before you get there, striving for and
attaining code validation is a good start. I know that Andrew does not
disagree with the need/desire for valid code - that's not what he has said.
But I think that de-linking code validation from accessible web development
is the edge or a slippery slope, it in effect says that standards can be
secondary to results - a point that flies in the face of logic to me.

>
> It may be that an ampersand in an href is not going to affect any
> known user agent, but if you're going to provide a guide for
> developers, I'd keep it simple: use valid code.

EXCEPT... Earlier in this thread my good friend Derek Featherstone pointed
out a situation (rare, but real) where a fouled ampersand *DID* negatively
affect the outcome (http://webaim.org/discussion/mail_message.php?id=10177).

> I have been in
> situations where developers were reluctant to use valid code because
> it meant changing their CMS, so I don't think it will necessarily be
> caught by other parts of the process.

And see, that's the point. If they are reluctant to something as basic as
code validation, and it is accepted that this is OK, then what happens when
they must do something else in the name of accessibility?

JF

From: John Foliot - Stanford Online Accessibility Program
Date: Tue, Feb 27 2007 4:10PM
Subject: Re: Well formed verses Valid code
← Previous message | Next message →

As an interesting side-note, the whole topic of code validation is discussed
at A List Apart - posted yesterday:
http://alistapart.com/articles/whereourstandardswentwrong





From: smithj7@peoplepc.com
Date: Tue, Feb 27 2007 9:00PM
Subject: Re: Well formed verses Valid code
← Previous message | No next message

Thanks! This was a timely article.
----- Original Message -----
From: "John Foliot - Stanford Online Accessibility Program"
< = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, February 27, 2007 6:01 PM
Subject: Re: [WebAIM] Well formed verses Valid code


> As an interesting side-note, the whole topic of code validation is
> discussed
> at A List Apart - posted yesterday:
> http://alistapart.com/articles/whereourstandardswentwrong
>
>
>
>
>
>