WCAG 2.0 questions
Does this test page pass the following WCAG 2.0 success criteria?
assuming a baseline of HTML.
Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies)
| Quote: |
|
Level 1 Success Criteria for Guideline 4.1 4.1.1 Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous. |
and
Guideline 1.4 Make it easy to distinguish foreground information from its background
| Quote: |
| Level 2 Success Criteria for Guideline 1.4
1.4.1 Text or diagrams, and their background, have a luminosity contrast ratio of at least 5:1. |
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share: 
ah...i see that we're thinking along the same lines as we're going through the wcag 2.0 last call...
for 4.1.1. it depends whether or not browsers turn the eclectic markup into one, and only one, DOM representation. i've never delved too deeply into HTML in terms of which things can be omitted (in light of its SGML roots) and where order is relevant ... but basically, as long as it follows the various rules in the DTD and SGML, and doesn't rely on browser's error handling (which can be inconsistent), it should pass 4.1.1.
as for 1.4.1., i'd argue that in the way that it's currently worded wcag 2.0 does not address contrast issues when it comes to images containing text.
Patrick H. Lauke / splintered
Share:
| stevefaulkner wrote: | ||
|
Does this test page pass the following WCAG 2.0 success criteria? assuming a baseline of HTML. Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies)
|
Parsed unambiguously is defined as, "parsed into only one data structure". If you examine the resulting DOM for that document in different user agents, the data structure is significantly different from user agent to user agent, which is listed in the understanding WCAG 2 document as a failure of this success criterion.
| stevefaulkner wrote: | ||
|
and Guideline 1.4 Make it easy to distinguish foreground information from its background
|
When a technology is used but isn't listed in the baseline, the technology must meet the guidelines with and without that technology enabled. When images and CSS are supported, the colour contrast of the text in the image against its background for the paragraph and the caption have a luminosity contrast ratio of 1:1.17, so fails as it's not at least 5:1.
Share:
| gez wrote: |
| When images and CSS are supported, the colour contrast of the text in the image against its background for the paragraph and the caption have a luminosity contrast ratio of 1:1.17, so fails as it's not at least 5:1. |
How does this square with the WCAG 2.0 defintion of non-text content?
| Quote: |
| non-text content
content that is not represented by a Unicode character or sequence of Unicode characters when rendered in a user agent according to the formal specification of the content type. |
Isn't a gif image of some text therefore non-text content, and not subject to 1.4.1? Or am I mis-understanding the definition above?
Dan Champion, Champion IS, Mooch Marketing, Revish
Share:
| danchamp wrote: | ||
|
How does this square with the WCAG 2.0 defintion of non-text content?
Isn't a gif image of some text therefore non-text content, and not subject to 1.4.1? Or am I mis-understanding the definition above? |
My interpretation is that this is a different, albeit related, issue. The colour contrast of text is applicable to all technologies that produce a visual output. The objective of the success criterion is to ensure that users can read text that is presented over a background, regardless of technology, so my interpretation is that it's relevant for images containing text.
Share:
| gez wrote: |
| The objective of the success criterion is to ensure that users can read text that is presented over a background, regardless of technology, so my interpretation is that it's relevant for images containing text. |
Thanks, that's what I thought. The objective is clear and easy to agree with, I just feel that the guidelines' current definitions of text and non-text content leave enough doubt for misinterpretation in this case.
Dan Champion, Champion IS, Mooch Marketing, Revish
Share:
| danchamp wrote: |
|
I just feel that the guidelines' current definitions of text and non-text content leave enough doubt for misinterpretation in this case. |
Yeah, I agree. It's worth making a comment to ensure that images of text are explicitly included by the success criterion. It might be considered an oxymoron according to their definition of text, but it would make it easier to understand.
Share:
thanks gez for clearing up the parsing question.
gez wrote:
| Quote: |
| It's worth making a comment to ensure that images of text are explicitly included by the success criterion. |
I think that it is very important that this be made clear, as the defintions of text and non-text content leads me, and my colleagues, to believe that images of text are not included (and that this was intentional).
Why? because if images of text have text alternatives these can be presented with an appropriate contrast.
If this is the case then it will actually encourage developers/designers to use images of text in order to get around the contrast limitations, which would be a real step backward.
Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Share:
The trouble is, you can't assume that anyone with reduced visual acuity will be using AT of any kind, still less something that will be able to read the relevant ALT text or LongDesc.
So... I agree that the definition of 'text' has to be all-embracing.
Share: