RE: Proposal to remove "B.2.1.1" (was B.1.1.1)

Hi Jan,

I'm not sure how any of those (B.2.2.2 etc) cover some quite fundamental content-accessibility requirements?

For example, a CMS that allows a user to add content that should be headings, lists and tables (under WCAG 2: 1.3.1  1.3.2). 
I.e. Common structural elements in HTML content.

B.2.2.2 talks primarily about attributes, source editing, time based media etc.

Thinking about the WYSIWYG context, a CMS could allow authors to format a line of text as bold 18pt, and not allow the use of headings. (I have seen WYSIWYG editors like this!)
It might not include a function for adding HTML tables, but allow cutting and pasting of tab-formatted content into a "formatted" section (a <pre>).

I strongly believe that there should be something in ATAG that enforces the "Info and Relationships" parts of WCAG. Otherwise, there is nothing to ensure that an ATAG-compliant tool allows a typical author to produce accessible content for a typical web page.

Given that WCAG 1.3.1. & 1.3.2 are both level-A, perhaps ATAG can provide levels for how it is met? In layman's terms:

Level A - Allows for the use of a source-code editor to meet WCAG 1.3.
Level AA - The default functionality produces accessible (structural) markup.
Level AAA - The tool enforces the use of structural markup.

I take on board Greg's comments from the survey, and I agree we can't expect tool providers to certify every possible permutation of the output.

Dreamweaver (from my memory of version 8?!) has both structural controls and a code view, therefore could meet this requirement at AA. If Contribute could be setup to restrict content to the structural elements, that would be AAA on this point. (It seem to remember that it can, but that was a while ago.)

The B.2.1.1 wording was quite general, and given that B.2.2.2 is aimed at attributes perhaps we can focus it on structural elements? Or modify B.2.2.2 to cover both?

Kind regards,

-Alastair

Received on Thursday, 10 February 2011 18:52:41 UTC