E-mail List Archives

Search E-mail List Archives for

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

From: Alastair Campbell
Date: Wed, Mar 08 2006 10:40AM
Subject: Code Validation
No previous message | Next message →

John Foliot wrote:
> > developer(s) have taken the time to ensure that their source
> > code meets validation requirements, that they have also taken
> > a reasonable amount of time to ensure other "accessibility"
> > requirements have been met, addressed, or at least considered.

Andrew Kirkpatrick then wrote:
> That is a huge assumption and while it may be anecdotally supported, I
> doubt that it is really statistically true. I'd be more
> willing to say that those who take the time to validate their
> pages are more likely to run a "Bobby" test

If people code to the HTML/CSS standards, I wouldn't say they are more
likely to take time to check accessibility requirements, but I do think
that:
A) They are much more likely to be aware of them, as there is a lot of
overlap where they are talked about (e.g. W3C).
B) It is likely there will be less issues with their pages anyway.

If the code is valid, you just have to worry about correctly using
structural elements, design aspects, usability aspects, and
cross-browser support. Ok, that is quite a bit, but a lot less than if
you've used a WYSIWYG for template creation.

You *can* make valid pages that are inaccessible, but you have to work
harder. I would put good money on a bet that the average site with valid
HTML is more accessible than the average site which uses tag soup.

The problem here is that there is no direct causal factor. However, on
balance, I would definitely come down on the side of including code
validity in the next version of the WCAG guidelines.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

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

From: John Foliot - WATS.ca
Date: Wed, Mar 08 2006 11:00AM
Subject: RE: Code Validation (was RE: spacing -  versus clear images)
← Previous message | Next message →

Andrew Kirkpatrick wrote:
> Should we start a pool?

I already stuck out my neck, but my *guess* is that we are still 2 years
out...

> Generally I don't need to but there does need to be decision making
> on the part of the developer to determine whether a particular
> technique is beneficial, harmful, valid, cheap, expensive, etc. in
> order to make the right decision for the scenario at hand.

Right, and those decisions are contrasted against... Standards.

>
> Standard constructs can also cease to be supported. No, I don't have
> a good example on hand, but there is no reason that it can't
> happen...

Well, here I will press you harder. (Much harder).

The whole point of Standards is that they remain "standard". As a
fundamental starting point, all future 'standards" are *supposed* to
degrade gracefully, or be supported by earlier Standards. That's the
point.

As an analogy, look at the lowly screw. Originally, most screws had
slot-top heads, and the blade screwdriver is *still* the most common
screwdriver out there. Yet in the world of modern manufacturing and
construction, the slot top screw has been superceded by either the
Philips (cross) or Robertson (square-tip), as, from an automated and
practical perspective these screws are easier to use. However,
regardless of the screw-top, they all share other common
characteristics, including lengths, thread sizes, etc., so that in the
absence of one type of screw top, a different, yet compatible solution
is readily available - that's Standards. PLUS, the tools (screw drivers)
are also manufactured to work with the screws, based upon standards.

As we develop web content "for the masses", we can often rely on
assumptions, however in the absence of a presumed scenario, what is the
fallback? If there is a Standards based solution, the fall-back exists,
and so the Accessibility perspective is addressed. It may not be as
pretty, as fast, or may miss some of the finer nuances, but the end goal
(access to the information) remains. Using non-standard "hacks"
potentially leaves open the door for total inaccessibility to some or
many users.

Finally, from a QA perspective, there is a generally held 'truth' that
hacks, workarounds and other 'non-standard' solutions have a nasty way
of reaching out and biting you on the behind at the least opportune
time. Look at all those poor souls who deployed various CSS hacks to
address IE 6's shortcoming, they now have to go back and repair all of
their work (http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx).
Developers who steered clear of hacks can read that article and smile to
themselves, as they continue to move forward, not having to go back and
rework existing stuff they spit out "back then".

>
> I can't take credit for all of the delay. This is a concern for
> Flash, as you know. With Flash in a web page for example, you need
> to choose between writing invalid code via javascript, writing static
> invalid code, valid code that is incompatible with screen readers,
> valid code that is incompatible with Mozilla, or writing valid code
> with an IE hack. I don't care which you use as long as the users are
> able to access the content. This is not a case of "ya but it works"
> but "hey - this doesn't work!".

And I will concede you this - I too have been forced to make compromises
based on browser inadequacies. But this is due, in part, to the fact
that the browsers (wait for it) do not also conform to the published
standards.

You mention an IE hack, and it is generally known that today IE 6 is the
least Standards compliant browser in current widespread usage (and yes,
I know the numbers, but they are shifting. Firefox in Canada has a
reported 25% market share, and I just saw an article last week that
claims that in the UK, Firefox has an 11% market share. And Microsoft
has release IE 7 as a beta, and one of their stated end-goals is to make
it more standards compliant).

So if we expect the browsers to be standards compliant, how can we
justify our use of hacks, work-arounds or other "solutions"?

>
>> developer(s) have taken the time to ensure that their source
>> code meets validation requirements, that they have also taken
>> a reasonable amount of time to ensure other "accessibility"
>> requirements have been met, addressed, or at least considered.
>
> That is a huge assumption and while it may be anecdotally supported,
> I doubt that it is really statistically true.

Perhaps, but I am an optimist at heart. As well, we in the
accessibility field continue to preach to the uninitiated, and asking
for/striving for accessible code is one of the easier checks to grasp,
because even the beginner can read a validation report and correct their
mistakes. Valid code does not require the subtle nuances and experience
required to access other WCAG guidelines (what, exactly, is appropriate
alt text, for example?).

> I'd be more willing to
> say that those who take the time to validate their pages are more
> likely to run a "Bobby" test, but not necessarily the manual tests.

Yes, I agree that there are a lot of wannabes and posers out there. It
is for this reason that I wish there were a more robust method of
holding these statements to the test. I anxiously await EARL's
ascension to a Recommendation (and which I had more time to be involved
in that initiative).

> I wonder what percentage of sites developed with valid code also use
> HTML headings and explicit label associations - I bet it's less than
> you might hope.

Perhaps, but more than I suspect you think. The rapid rise of Standards
based blogging tools, the advances in SEO techniques, etc. have all
impacted on the 'force' of valid code development, especially the proper
use of headings. Explicit label associations may be harder, but the
current crop of WYSIWYG dev tools have at least made this a lot easier
to accomplish. There is no substitute for proper education however.

JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053

From: Andrew Kirkpatrick
Date: Wed, Mar 08 2006 1:30PM
Subject: RE: Code Validation (was RE: spacing -  versus clear images)
← Previous message | Next message →

> > Should we start a pool?
>
> I already stuck out my neck, but my *guess* is that we are
> still 2 years out...

Oooh! We _should_ start a pool! I'll bet sooner than 2 years.

> > Generally I don't need to but there does need to be
> decision making on
> > the part of the developer to determine whether a particular
> technique
> > is beneficial, harmful, valid, cheap, expensive, etc. in
> > order to make the right decision for the scenario at hand.
>
> Right, and those decisions are contrasted against... Standards.

Sure. I'm not anti-standards!

> The whole point of Standards is that they remain "standard".
> As a fundamental starting point, all future 'standards" are
> *supposed* to degrade gracefully, or be supported by earlier
> Standards. That's the point.

I'm not sure I agree with the latter part. I'm not enough a standards
wonk to tell you whether all standards are really supposed to degrade to
something prior.

> As an analogy, look at the lowly screw. Originally, most
> screws had slot-top heads, and the blade screwdriver is
> *still* the most common screwdriver out there. Yet in the
> world of modern manufacturing and construction, the slot top
> screw has been superceded by either the Philips (cross) or
> Robertson (square-tip), as, from an automated and practical
> perspective these screws are easier to use. However,

Have you ever tried to use a blade screwdriver with a Robertson screw
head? Didn't someone decide that a particular variant method was somehow
better for them? Or was Robertson a standards committee? Shouldn't
Robertson screw heads have a blade slot also? (Maybe they did until
"screw agent support" was sufficiently widespread!).

I'm being difficult, but all I want is for there to be room for people
to use their brains when developing. If you don't want to think, then
you absolutely should use the standards. Even if you do want to think
you will probably arrive at the same conclusion, but maybe you won't.
Thinking is good.

> shortcoming, they now have to go back and repair all of their
> work (http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx).

This was, for those who thought about it, a chance that they took in
order to accomplish a goal that existed originally. Part of thinking
through the situation is recognizing that a current solution may not
work forever.

> Developers who steered clear of hacks can read that article
> and smile to themselves, as they continue to move forward,
> not having to go back and rework existing stuff they spit out
> "back then".

That's great that they can enjoy watching those who employed hacks
getting their comeuppance, but are those developers' sites left with the
same look that they may not have been pleased with settling on because
they didn't use some useful hack? Maybe. So then they go and redesign
it again anyway? Possibly. Sites need maintainence.

> And I will concede you this - I too have been forced to make
> compromises based on browser inadequacies. But this is due,
> in part, to the fact that the browsers (wait for it) do not
> also conform to the published standards.

Sure. So you looked at the alternatives, thought about it, and made the
best decision. Sounds great. That's different than strict
standards-compliance.

> So if we expect the browsers to be standards compliant, how
> can we justify our use of hacks, work-arounds or other "solutions"?

It takes more than expectations. Developers need the browsers and other
user agents to _be_ standards compliant before we can consistently avoid
hacks.

> > I wonder what percentage of sites developed with valid code
> also use
> > HTML headings and explicit label associations - I bet it's less than
> > you might hope.
>
> Perhaps, but more than I suspect you think. The rapid rise
> of Standards based blogging tools, the advances in SEO
> techniques, etc. have all impacted on the 'force' of valid
> code development, especially the proper use of headings.

If we're talking about a per-developer instance, you don't get to count
all of the google and movable type blogs individually!

> Explicit label associations may be harder, but the current
> crop of WYSIWYG dev tools have at least made this a lot
> easier to accomplish.

Glad to hear!

AWK

Andrew Kirkpatrick
Accessibility Engineer
Adobe Systems
= EMAIL ADDRESS REMOVED =

From: Joshue O Connor
Date: Thu, Mar 09 2006 5:20AM
Subject: Re: Code Validation (was RE: spacing -   versus clearimages)
← Previous message | No next message

Hi Andrew,

> I'm not enough a standards
> wonk

Whats a wonk?

Does it mean we can call people who blindly follow "standards" as "wonkers" ;)

>> Thinking is good.

It sure is.

Josh

Joshue O Connor

Senior Accessibility Consultant

**Centre for Inclusive Technology (CFIT)* *
National Council for the Blind of Ireland

Website:http://www.cfit.ie
E-Mail: = EMAIL ADDRESS REMOVED =
Tel: +353 1 8821915




Andrew Kirkpatrick wrote:
>>>Should we start a pool?
>>
>>I already stuck out my neck, but my *guess* is that we are
>>still 2 years out...
>
>
> Oooh! We _should_ start a pool! I'll bet sooner than 2 years.
>
>
>>>Generally I don't need to but there does need to be
>>
>>decision making on
>>
>>>the part of the developer to determine whether a particular
>>
>>technique
>>
>>>is beneficial, harmful, valid, cheap, expensive, etc. in
>>>order to make the right decision for the scenario at hand.
>>
>>Right, and those decisions are contrasted against... Standards.
>
>
> Sure. I'm not anti-standards!
>
>
>>The whole point of Standards is that they remain "standard".
>>As a fundamental starting point, all future 'standards" are
>>*supposed* to degrade gracefully, or be supported by earlier
>>Standards. That's the point.
>
>
> I'm not sure I agree with the latter part. I'm not enough a standards
> wonk to tell you whether all standards are really supposed to degrade to
> something prior.
>
>
>>As an analogy, look at the lowly screw. Originally, most
>>screws had slot-top heads, and the blade screwdriver is
>>*still* the most common screwdriver out there. Yet in the
>>world of modern manufacturing and construction, the slot top
>>screw has been superceded by either the Philips (cross) or
>>Robertson (square-tip), as, from an automated and practical
>>perspective these screws are easier to use. However,
>
>
> Have you ever tried to use a blade screwdriver with a Robertson screw
> head? Didn't someone decide that a particular variant method was somehow
> better for them? Or was Robertson a standards committee? Shouldn't
> Robertson screw heads have a blade slot also? (Maybe they did until
> "screw agent support" was sufficiently widespread!).
>
> I'm being difficult, but all I want is for there to be room for people
> to use their brains when developing. If you don't want to think, then
> you absolutely should use the standards. Even if you do want to think
> you will probably arrive at the same conclusion, but maybe you won't.
> Thinking is good.
>
>
>>shortcoming, they now have to go back and repair all of their
>>work (http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx).
>
>
> This was, for those who thought about it, a chance that they took in
> order to accomplish a goal that existed originally. Part of thinking
> through the situation is recognizing that a current solution may not
> work forever.
>
>
>>Developers who steered clear of hacks can read that article
>>and smile to themselves, as they continue to move forward,
>>not having to go back and rework existing stuff they spit out
>>"back then".
>
>
> That's great that they can enjoy watching those who employed hacks
> getting their comeuppance, but are those developers' sites left with the
> same look that they may not have been pleased with settling on because
> they didn't use some useful hack? Maybe. So then they go and redesign
> it again anyway? Possibly. Sites need maintainence.
>
>
>>And I will concede you this - I too have been forced to make
>>compromises based on browser inadequacies. But this is due,
>>in part, to the fact that the browsers (wait for it) do not
>>also conform to the published standards.
>
>
> Sure. So you looked at the alternatives, thought about it, and made the
> best decision. Sounds great. That's different than strict
> standards-compliance.
>
>
>>So if we expect the browsers to be standards compliant, how
>>can we justify our use of hacks, work-arounds or other "solutions"?
>
>
> It takes more than expectations. Developers need the browsers and other
> user agents to _be_ standards compliant before we can consistently avoid
> hacks.
>
>
>>>I wonder what percentage of sites developed with valid code
>>
>>also use
>>
>>>HTML headings and explicit label associations - I bet it's less than
>>>you might hope.
>>
>>Perhaps, but more than I suspect you think. The rapid rise
>>of Standards based blogging tools, the advances in SEO
>>techniques, etc. have all impacted on the 'force' of valid
>>code development, especially the proper use of headings.
>
>
> If we're talking about a per-developer instance, you don't get to count
> all of the google and movable type blogs individually!
>
>
>>Explicit label associations may be harder, but the current
>>crop of WYSIWYG dev tools have at least made this a lot
>>easier to accomplish.
>
>
> Glad to hear!
>
> AWK
>
> Andrew Kirkpatrick
> Accessibility Engineer
> Adobe Systems
> = EMAIL ADDRESS REMOVED =
>
>
>
>
>
>