Re: The Disunity of W3C Specs

Geoff,

>What do developers use a TRANSITIONAL DTD for?  Mostly it is used when
>tables are required for layouts.  With the recent discussion on not
>requiring <TH> in tables that are only used for layouts, I feel this is
>something that if the WAIGL feels is important, it has to go to the Markup
>GL to get changed.  In this case I would suggest things along the lines of
>
>* TRANSITIONAL DTD = <TH> is optional, summary is optional
>* STRICT DTD = <TH> is required, summary is required

We are not suggesting that TH is required on _all_ tables.  We are 
suggesting that if you use a table for layout that you do not use TH in 
that table.  We are suggesting that TH is required only for tables that 
present data (i.e., cells can not stand alone, there is a relationship 
between cells) and not for tables used for layout (i.e., each cell should 
be able to stand on its own).

The HTML WG has said that tables are for data only and that there are 
better mechanisms for layout.  However, today, developers are still 
developing for user agents that do not support CSS positioning well and 
many authoring tools are still generating tables as the primary means for 
layout.  We are caught between the future-thinking ideal and the current 
reality.

>And new items like the element attribute contextHelp have to be added to the
>next version of the Markup before they become a formal recommendation or
>considered by WAIGL, cause this type of thing is driving developers crazy.

Before we include a technique describing a new element/attribute (such as 
contextHelp) we will make sure it is included in an industry-accepted 
specification or is a widely-used technique.  For example, "embed" does not 
appear in the HTML specs but since "object" isn't supported consistently 
(or at all in some user agents) we suggest how to use it in an accessible way.

>Take the recent discussion on <ACRONYM> and <ABBR> here, when the XHTML 2.0
>proposes to drop <ACRONYM>.  Why support something in WCAG 2.0 that will be
>deprecated?  Why even bother with something that the Markup GL sees fit to
>deprecate.  I know it hasn't happened yet, but it looks like it.

XHTML 2.0 isn't a W3C Recommendation, yet.  WCAG WG should address the 
needs of developers who want to make content accessible *today.*   In the 
Techniques Task Force we have discussed labeling techniques as "legacy" or 
"deprecated" or "future" to help clarify these distinctions for developers.

>I think Mark Pilgrim's frustration
>(http://diveintomark.org/archives/2003/01/13/semantic_obsolescence) as
>representative of a lot of developers who are trying to do the right thing,
>but are caught in the fragmentation that happens, even though this whole
>process is about trying to readdress just that point.  There are a lot of
>them out there that are trying to do the right thing.

There are many pieces to the puzzle.  Why haven't user agent developers 
implemented the standards that they helped develop?  Why don't users update 
their browsers each time a new one is released?  Why don't authoring tools 
generate valid code?  There are several answers to each of these questions.

>What is going to happen is that we are not going to end up with a formal set
>of grammars, but just a better and improved HTML soup.
>
>Currently, I think the only developer who can get this type of thing right
>is one who has full access to configuring their web server, deploying
>transparent content negotiation, and transforming their documents using
>XSLT.  Otherwise there is just too many sets of variables.
>
>If there is fragmentation between the Markup standards and the Accessibility
>standards, then web developers will ignore whatever is fragmented.  If
>possible they only want to deal with one validator, which represents a
>unification of standards.

Some of our recommendations will be for HTML 4.01 others will be for XHTML 
1.0/1.1.  We'll stay aware of developments in XHTML 2.0.  We will clearly 
label if a technique is for HTML 4.01 or XHTML 1.  Where we have ideas 
about accessibility improvements in XHTML we will discuss them with the 
Protocols and Formats Working Group (PFWG [1]) who is our primary contact 
with other W3C working groups (per our charters) and is actively monitoring 
development of XHTML 2.0.  An historical example: during work on WCAG 1.0, 
we worked with PFWG on accessibility features for HTML that were adopted by 
the HTML WG and included in the HTML 4.01 spec.

Thanks for voicing your concerns and helping to make sure we contribute to 
the W3C mission. I hope this calms your frustrations/fears. If not, let's 
figure out what we need to do.

Best,
--wendy

[1] http://www.w3.org/WAI/PF/

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Friday, 29 August 2003 19:50:48 UTC