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

Hi Alastair,

"Enforcement" of structural relationships in general is tricky because recognizing relationships often requires human judgement (e.g., a line of text in bold 18 pt font might just be something an author REALLY wanted to emphasize, not a heading)

The best a tool can usually do is attempt to check with heuristics, which is why I suggested things might be covered by B.3.1.1 Checking Assistance (WCAG) and B.3.2.1 Repair Assistance (WCAG)

Here's another thought....

What if I type this as my FB status update using hard returns:
"
Big day today...Bonnie said I can't believe you're moving to Timbuktu....so much to pack...
Clothes:
Hiking shoes
Sun hat
Equipment:
Compass
Books to read
"

Should Facebook fail because it doesn't warn me that "Clothes:" and "Equipment:" should be headings (this seems silly)? Or is there some use in a "simple, unstructured text" exception. I'd be ok with this I think. For me, the real problem are tools that represent themselves as creating structured markeup (e.g., headings) but then fail to use structural markup underneath. 

Thoughts?
-Jan

-- 
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University


> -----Original Message-----
> From: Alastair Campbell [mailto:acampbell@nomensa.com]
> Sent: February 10, 2011 1:52 PM
> To: Richards, Jan
> Cc: AUWG
> Subject: 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 Friday, 11 February 2011 21:26:23 UTC