{"id":113,"date":"2006-06-07T05:52:37","date_gmt":"2006-06-07T05:52:37","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2006\/06\/wcag2"},"modified":"2006-06-18T03:31:21","modified_gmt":"2006-06-18T03:31:21","slug":"wcag2","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2006\/06\/wcag2","title":{"rendered":"WCAG 2.0"},"content":{"rendered":"

In a recent controversial article on A List Apart, Joe\r\n\t\tClark<\/a> proclaimed\r\n\t\tTo Hell with WCAG\r\n\t\t2<\/a>. On the surface, it seems like Joe made a strong case\r\n\tagainst the WCAG 2.0 draft in an attempt to rally support for his movement\r\n\t\tagainst the WCAG Working Group. Although he did raise many issues, in\r\n\t\tseveral cases he failed explain exactly what the problem is.<\/p>\r\n

I\u2019m fully aware of the fact that not everyone who reads Joe\u2019s article will\r\n\twade through several hundred pages from the 3 WCAG specifications, and who could\r\n\tblame you? I read them, but the specs are certainly long, tedious and, in many\r\n\tcases, extremely difficult to comprehend.<\/p>\r\n\r\n

\r\n\t

Exactly what a \u201cpage\u201d is, let alone a \u201csite,\u201d will be a matter of dispute.<\/p>\r\n<\/blockquote>\r\n

I somewhat agree with this. In an attempt to be technologically independent,\r\n\tcommon terms like \u201cpage\u201d and \u201csite\u201d have been replaced with much more obscure\r\n\ttechnical terms like \u201cweb\r\n\tunit<\/a>\u201d, \u201cauthored\r\n\tunit<\/a>\u201d and \u201cauthored\r\n\tcomponent<\/a>\u201d. \r\n\tSome of these terms aren\u2019t even clearly defined or easily distinguishable from\r\n\teach other.<\/p>\r\n

For instance, consider \u201cauthored unit\u201d and \u201cweb unit\u201d: two terms that have\r\n\tdifferent definitions, but I still can\u2019t quite figure out what exactly distinguishes\r\n\ta \u201cset of material created as a single body by an author\u201d from \u201ca collection\r\n\tof information, consisting of one or more resources, intended to be rendered\r\n\ttogether\u201d. <\/p>\r\n\r\n

\r\n\t

A future website that complies with WCAG 2 won\u2019t need valid HTML\u2014at all,\r\n\t\tever. (More on that later.) You will, however, have to check\r\n\t\tthe DOM outputs of your site in multiple browsers<\/a> and prove they\u2019re identical.<\/p>\r\n<\/blockquote>\r\n

There are two issues here: whether or not validity should be required by WCAG\r\n\t2.0 and the insanity of that particular technique. I\u2019m sure everyone agrees\r\n\tthat comparing the DOMs is an unrealistic expectation; and besides, the technique\r\n\tis non-normative and so it can be safely ignored.<\/p>\r\n

In the current draft of the guidelines, success\r\ncriterion 4.1.1<\/a> states:<\/p>\r\n

\r\n\t

Web units or authored components can be parsed unambiguously, and the relationships\r\n\t\tin the resulting data structure are also unambiguous.<\/p>\r\n<\/blockquote>\r\n

How to Meet Success Criterion 4.1.1<\/a> \r\n\tclarifies the meaning of that a little, though it still\r\n\tuses rather technical lingo. It basically means that documents can be parsed\r\n\tproperly without depending upon error recovery techniques, especially where\r\n\tthe results are inconsistent between browsers. Strictly speaking, the wording\r\n\tof that success criterion doesn\u2019t explicitly require documents to be valid;\r\n\thowever, one of the techniques described to meet it is in fact Validating\r\n\t\tWeb Units<\/a>.<\/p>\r\n

Personally, I\u2019m not convinced validity should be strictly required by WCAG\r\n\t2.0, I believe it should remain as just a technique. The success criteria should\r\n\tinstead outline the purpose of validation. In other words, if you were asked:\r\n\twhy validate?<\/em> What would your answer be and how does it relate to accessibility?<\/p>\r\n

As it currently stands, the working group seems to recognise that the purpose\r\n\tof validation is to help ensure that documents can be parsed correctly and interoperably\r\n\tbetween user agents. It\u2019s important to realise that validation is just a technique,\r\n\tnot a goal in itself.  It is indeed a very good technique and one that\r\n\tcan be used to help meet the success criterion; but it is technique none-the-less.<\/p>\r\n

I’m not saying validation isn’t important.  I do believe it is very important\r\n\tand I personally insist upon it for any site I develop, but it needs to be put\r\n\tinto the proper context. Although I wouldn\u2019t object to its inclusion in the\r\n\tguidelines, I don’t believe it needs to be enforced as a requirement on its\r\n\town. If validation is to succeed in web development, it should instead succeed\r\n\tas part of quality assurance and best practice guidelines.<\/p>\r\n

\r\n\t

You can still use tables for layout. (And not just a<\/em> table\u2014tables<\/em> for\r\n\t\tlayout<\/a>, plural<\/a>.)<\/p>\r\n<\/blockquote>\r\n

It is unfortunate the wording of these guidelines explicitly allows the use\r\n\tof tables for layout and does very little to discourage their use. While I\r\n\tbelieve it should be recognised that table layouts can be made relatively accessible\r\n\tto assistive technology, their use should still be considered a failure.<\/p>\r\n

\r\n\t

Your page, or any part of it, may blink\r\n\t\t\tfor up to three seconds<\/a>. Parts\r\n\t\t\tof it<\/a> may not, however, \u201cflash.\u201d<\/p>\r\n<\/blockquote>\r\n

I don\u2019t particularly like blinking or flashing content at all, but I\u2019m not\r\n\texactly sure of the problem here. It seems to me that the guideline recognises\r\n\tthat prolonged blinking\/flashing is an accessibility issue and addresses it\r\n\tby limiting the time frame.<\/p>\r\n

I\u2019m no expert on the issue, nor am I aware of the use cases (beyond annoying\r\n\tadvertisements) for allowing any blinking at all, but 3 seconds seems like a\r\n\treasonable compromise to me. Is 3 seconds enough time to trigger an epileptic\r\n\tseizure or any other specific problems? Or is it merely an objection based\r\n\ton a personal dislike of blinking, rather than solid facts?<\/p>\r\n

\r\n\t

You\u2019ll be able to define entire technologies as a \u201cbaseline<\/a>,\u201d\r\n\t\tmeaning anyone without that technology has little, if any, recourse to complain\r\n\t\tthat your site is inaccessible to them. <\/p>\r\n<\/blockquote>\r\n

I don\u2019t fully agree with this issue and while I do see the conceptual problem\r\n\twith the baseline, I don\u2019t believe it is as bad as some people make it out to\r\n\tbe.<\/p>\r\n

There is a major difference between the statements: \u201cThis site is accessible\u201d\r\n\tand \u201cThis site is accessible to users, whose UAs meet the baseline requirements\u201d.\r\n\tWhile the latter will theoretically apply to any document conforming to WCAG\r\n\t2.0, the former is a much broader statement that effectively means \u201cThis site\r\n\tis accessible [to everyone]\u201d.<\/p>\r\n

If your baseline is set too high, users will have \u201crecourse to complain that\r\n\tyour site is inaccessible to them\u201d. The problem is that there is little guidance\r\n\ton specifying a realistic, accessible baseline and that means the concerns\r\n\tabout it being set too high by organisations are indeed valid. For example,\r\n\tif you\u2019re baseline includes JavaScript, anyone that chooses to disable JavaScript\r\n\twill be effectively denied access to the site because their UA doesn\u2019t meet\r\n\tthe requirements. This goes against the very principle of Unobtrusive JavaScript<\/em>\tand I see how this is a serious problem.<\/p>\r\n

On the other hand, it\u2019s an unrealistic expectation that plain old HTML will\r\n\tbe able to meet every possible use case and, as Joe will you tell you himself,\r\n\tother technologies can be made just as accessible (e.g. Accessibile\r\n\tPDFs<\/a>).<\/p>\r\n\r\n

\r\n\t

You\u2019ll be able to define entire directories of your site as off-limits to\r\n\t\taccessibility (including, in WCAG 2\u2019s own example, all\r\n\t\tyour freestanding videos<\/a>).<\/p>\r\n<\/blockquote>\r\n

I don\u2019t see how this is a serious problem. The ability to scope a conformance\r\n\tstatement to specific sections of the site has some very good use cases. Although\r\n\tfailing to meet conformance for one section simply because the author doesn\u2019t\r\n\twant to do so isn\u2019t a very good excuse, the ability to scope a conformance claim\r\n\tis better than lying by saying the whole site is accessible.<\/p>\r\n\r\n

\r\n\t

Not that anybody ever made them accessible, but if you post videos online,\r\n\t\tyou no longer have to provide audio descriptions for the blind at the\r\n\t\tlowest \u201cconformance\u201d level<\/a>. And only prerecorded videos require captions\r\n\t\tat that level.<\/p>\r\n<\/blockquote>\r\n

I\u2019m not sure how either of these are serious issues. Those with the knowledge\r\n\tand tools available to provide audio descriptions of video can still do so,\r\n\tbut requiring audio descriptions at the lowest level is an unreasonable expectation\r\n\tfor most authors who are unlikely to have the technical skills, let alone\r\n\tthe tools, to do so.<\/p>\r\n

Such authors can still provide a full text alternative\r\n\twhich is much easier to produce. However, Joe claimed that the full text\r\n\talternative is a \u201cdiscreditied holdover from WCAG 1\u201d, yet failed to provide\r\n\tor link to any evidence to support that claim. His explanation stating\r\n\tthat parts of it are not needed by the blind, and other parts by the deaf\r\n\tdoesn’t seem to have a point \u2013 it certainly does nothing to discredit the\r\n\ttechnique.<\/p>\r\n

As for requiring captions for pre-recorded videos only, I don\u2019t understand\r\n\twhy this is a problem at all. Would anyone seriously expect the average\r\n\tperson with a live web cam to be able to provide captions in real time? \r\n\tThat would require some serious effort to do, which the average author couldn\u2019t\r\n\tpossible do anyway. Of course it may be realistic for something like a television\r\n\tstudio broadcasting their news online to provide captions, just as they do\r\n\tfor TV, in which case, they can claim conformance to a higher level of accessibility.<\/p>\r\n\r\n

\r\n\t

Your podcasts may have to be remixed so that dialogue is 20\r\n\t\t\tdecibels louder than lengthy background noise<\/a>.<\/p>\r\n<\/blockquote>\r\n

That is only if authors wish to claim conformance to level 3, although I don\u2019t\r\n\tunderstand what the problem is here. Is this an issue because the technique\r\n\tpresents no accessibility benefits? Is it because it’s an unrealistic\r\n\texpectation for authors to achieve? Or is there some other reason that failed\r\n\tto be explained. <\/p>\r\n\r\n

\r\n\t

You can\u2019t use offscreen positioning to add labels (e.g., to forms) that\r\n\t\tonly some people, like users of assistive technology, can perceive. Everybody<\/a><\/em> has\r\n\t\tto see them.<\/p>\r\n<\/blockquote>\r\n

I interpret the specification differently from Joe, with regards\r\n\tto this issue. How to Meet Success Criterion 1.3.1<\/a> states:<\/p>\r\n

\r\n\t

The intent of this success criterion is to ensure that information and relationships\r\n\t\tthat are implied by visual or auditory formatting are preserved when the presentation\r\n\t\tformat changes. […] The purpose of this success criterion is to ensure that\r\n\t\twhen such relationships are perceivable to one set of users, those relationships\r\n\t\tcan be made to be perceivable to all.<\/p>\r\n<\/blockquote>\r\n

Not everybody has to see the text labels; there is nothing there that says\r\n\tthey can\u2019t be hidden off screen. What I believe it is saying is that the\r\n\tsame meaning needs to be conveyed to all users, regardless of the presentation.\r\n\te.g. For a visual user, the meaning may be conveyed through the visual layout,\r\n\tcolours, icons, etc, but for an aural user, for example, the same meaning\r\n\tmay be conveyed by speaking the text label.<\/p>\r\n

\r\n\t

CSS layouts, particularly those with absolutely-positioned elements that\r\n\t\tare removed from the document flow, may simply be prohibited<\/a> at\r\n\t\tthe highest level. In fact, source order must match presentation order even\r\n\t\tat the lowest level.<\/p>\r\n<\/blockquote>\r\n

Again, I interpret the spec differently. Nothing in the spec\r\n\tsays the presentation order much match the source order, it simply states\r\n\tthat the same meaning must be conveyed to the user regardless of the presentation.\r\n\tIt\u2019s ok to use absolute positioning (or any other layout method) to alter\r\n\tthe presentational ordering, as long as the meaning of the content is not altered.<\/p>\r\n

\r\n\t

Also at the highest level, you have to provide\r\n\t\t\ta way<\/a> to find all of the following:<\/p>\r\n\t

    \r\n\t\t
  1. Definitions of idioms and \u201cjargon\u201d<\/li>\r\n\t\t
  2. Expansion of acronyms<\/li>\r\n\t\t
  3. Pronunciations<\/em> of some words<\/li>\r\n\t<\/ol>\r\n<\/blockquote>\r\n

    Again, I don\u2019t see how this is a problem at all. It is only required for\r\n\tlevel 3 conformance and is there any reason why providing such things would\r\n\tbe a bad idea? Providing definitions may be as simple as linking to a glossary\r\n\tor dictionary entry and expansions for acronyms is as simple as using the <abbr><\/code> and <acronym><\/code> elements.\r\n\tProviding pronunciations of some words, where necessary, is not only useful\r\n\tfor disabled, it’s useful for anyone that reads a difficult word they’ve\r\n\tnever heard before and may not have an obvious pronunciation.<\/p>\r\n

    WCAG Samurai<\/h3>\r\n

    Joe also announced the launch of the WCAG\r\n\t\tSamurai<\/a>: an effort to publish corrections\r\n\tfor and extensions to the existing WCAG 1.0 recommendation. In principle, it’s\r\n\ta very good idea for the community to begin addressing accessibility issues\r\n\tand the serious problems with WCAG 2.0 themselves, but my main concern with\r\n\tthe WCAG Samurai is this:<\/p>\r\n

    \r\n\t

    … another thing we\u2019re not going to do is run a totally open process. It\u2019s\r\n\t\ta viable model for standards development, one I have championed in another context,\r\n\t\tbut in web accessibility it is proven not to work.<\/p>\r\n<\/blockquote>\r\n

    \r\n\t

    WCAG Samurai will toil in obscurity for the foreseeable future. Membership\r\n\t\trolls will not be published, and membership is by invitation only.<\/p>\r\n<\/blockquote>\r\n

    Working on this behind closed doors seems like a huge mistake to me. In fact,\r\n\tit seems down right hypocritical of Joe to discredit the WCAG 2.0 working group\r\n\tprocess on the grounds that it and, indeed, the results themselves are inaccessible\r\n\tto a wide audience; only to go ahead and make the WCAG Samurai process inaccessible\r\n\tto, and hidden away from, all but the few invited elite.<\/p>\r\n

    I’m not too concerned that participation is strictly limited to the select\r\n\tfew, but I think there really needs to be a way for the community to at least\r\n\twatch from the sidelines and see everything that goes on, even if they can’t\r\n\tcontribute directly. It has been stated that the WCAG Samurai website will\r\n\tsoon have a news feed for updates, so there is a chance that\u2019s exactly what\r\n\twe\u2019ll get. <\/p>\r\n

    I will admit, however, it may be too early to pass judgement on the WCAG Samurai\r\n\tright now, and it’s only fair that we let them give it a shot. After all, the\r\n\tmembers are unlikely to be weighed down by absurd corporate interests, but rather\r\n\thave the best interests of both web developers and end users in mind. We\u2019ll\r\n\tjust have to wait and see.<\/p>\r\n","protected":false},"excerpt":{"rendered":"In a recent controversial article on A List Apart, Joe Clark proclaimed To Hell with WCAG 2. On the surface, it seems like Joe made a strong case against the WCAG 2.0 draft in an attempt to rally support for his movement against the WCAG Working Group. Although he did raise many issues, in several cases he failed explain exactly what the problem is.","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-113","post","type-post","status-publish","format-standard","hentry","category-accessibility"],"_links":{"self":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/comments?post=113"}],"version-history":[{"count":0,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/113\/revisions"}],"wp:attachment":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/media?parent=113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/categories?post=113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/tags?post=113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}