- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Fri, 11 Feb 2011 23:09:09 +0000
- To: "Richards, Jan" <jrichards@ocad.ca>
- CC: AUWG <w3c-wai-au@w3.org>
On 11 Feb 2011, at 21:25, Richards, Jan wrote: > "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) I would suggest though that if a tool can provide that functionality, it can also provide headings. I'm not saying you shouldn't be able to create a particular styling without structural markup (at least until level AAA), but that if you can create that styling that you can (level A), or default to (level AA) structural markup. I.e. the tool shouldn't have to make a judgement, but it should: Level A: Provide the ability to use structural markup. Level AA: Default to structural markup. Level AAA: Enforce structural markup. > 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) But there is nothing *at all* in ATAG to suggest that it should have headings! The checking aspect is good, but there has to be something that suggests or enforces that a tool should provide the ability to apply structural markup. It might be dependant on a certain level of functionality, but we have to have something. > Here's another thought.... > > What if I type this as my FB status update using hard returns: Facebook only allows plain text. If it allowed (rich) text formatting it could (and should) provide structural markup. > 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. Yep, me to. If you provide the ability to create what looks like headings, you should provide the (default?) ability to use heading markup. That's why I was previously suggesting an approach where if you *can* create an issue for WCAG (e.g. 1.3.x) that it allows or enforces (depending on the level) the author to create WCAG complaint content. If writing something for that in general terms leaves it too open (and I suspect it might!), then can we aim it at structural markup (WCAG 1.3.x), when the tool has sufficient functionality that authors could create an issue in the first place? I'll try and make it into a proposal / text for the survey comment over the weekend. -Alastair
Received on Friday, 11 February 2011 23:09:55 UTC