FW: [Irl-dean] False Accessibility Developers

Paul Walsh, Segala paul at segala.com
Tue Apr 11 21:29:09 IST 2006

Apologies if you have received this twice, the original was bounced back. 

      -----Original Message-----
      From: Paul Walsh, Segala [mailto:paul at segala.com] 
      Sent: 11 April 2006 20:43
      To: 'irl-dean at list.eeng.dcu.ie'
      Subject: RE: [Irl-dean] False Accessibility Developers
      Below please find my belated response. It has been a 
      while since I started this email so apologies if the 
      points that I'm addressing isn't obvious. 
      A general rule of thumb
      I think a fundamental principal needs to be addressed by 
      accessibility evangelists before heading out late at 
      night jumping between shadows to review websites for 
      compliance. The first thing to do is establish a site 
      owners claim for compliance. If they don't claim to 
      comply with specific guidelines, don't assume their site 
      isn't compliant because it fails your specific tests. I 
      agree with Barry regarding his comments for independent 
      verification, not because Segala is in this space, but 
      because it's a basic principal of software development of 
      any kind. 
      To address Hugh's email, accessibility is a site owners 
      responsibility so they should provide themselves with a 
      safety net of confidence by having their site verified by 
      a qualified independent verification company that 
      specialises in standards compliance. If this isn't 
      feasible, an internal review that's independent from the 
      development team is the next best thing.
      Fortunately the W3C Mobile Web Initiative is learning 
      from the WAI mistakes by taking all of these elements 
      into consideration. That is, the machine-readable 
      trustmark that will represent compliance with its best 
      practices, mobileOK, will enable tools such as search 
      engines to differentiate between self-labelled sites and 
      sites that have been verified by independent 
      certification providers. 
      One of the working groups within the WAI is called the 
      Evaluations and Reporting Tools (ERT) group which focuses 
      on a reporting language based on Semantic methods to 
      record test assertions amongst other testing materials. 
      Test results can then later be used as a means of proving 
      compliance. This is likely to be used in conjunction with 
      future compliance statements with W3C guidelines and best 
      Do you think an accessibility policy statement is a good idea?
      Website owners would benefit from providing an 
      accessibility policy that describes its compliance claims 
      as it would provide them with the opportunity to 
      demonstrate their commitment to accessibility long term, 
      rather than waiting for an entire site to comply in the 
      future. I personally see this becoming a legal 
      requirement like privacy policy statements. I think the 
      enforcement of an accessibility policy statement would be 
      a good start, even if one was to state that the site 
      complies with only a small number of WAI guidelines. What 
      do you think about this? Am I making sense? :)
      Does validity equal accessibility?
      Valid markup is a desirable best practice because it 
      reduces the chances of assistive technologies having 
      trouble reading a site, it's less work for browsers to 
      render content correctly and page weight may be lighter. 
      However the flip side of the argument is that validity 
      doesn't necessarily equal accessibility, so don't kill 
      yourself or spend lots of money on validity if the site 
      is accessible anyway. So, although a site could fail a 
      HTML validity check, it could still comply with every 
      other checkpoint and be usable by people who rely on 
      assistive technology. A large site may be accessible to 
      the widest possible audience and still have invalid 
      markup as a result of a CMS throwing out invalid code. Is 
      this the end of the world? Some think it is.
      My argument for XHTML(MP) is that it significantly 
      increases the possibility of device independence and 
      therefore a greater chance of a site working on small 
      screens such as PDAs. This may not be a huge requirement 
      today, but it will be very soon. Although it does have a 
      downside as pointed out by others.
      Are you forced to use PNG all of the time?
      Re PNG - the guideline states Use W3C technologies when 
      they are available and appropriate for a task. The clue 
      is in the wording, i.e. when they are available and 
      appropriate. Example, it's not wise to use PNG for images 
      that require high quality resolution such as photographs 
      because the quality would be pretty crap. Many software 
      developers were caught by surprise when it was revealed 
      that the GIF format had been patented by Unisys, and that 
      they would have to pay royalties for writing programs 
      that generated (or displayed) GIF files. The desire for a 
      comparable format with fewer legal restrictions (as well 
      as fewer technical restrictions such as the number of 
      colours) led to the development of the PNG (Portable 
      Network Graphics) standard. Although the GIF patents will 
      expire in the near future, PNG is still touted as a 
      technically superior alternative, and has become the 
      third most common image format on the web. I personally 
      don't have a strong emotion tied to this guideline.
      The null attribute should be used in alt tags for 
      decorative images. WCAG 1.0 is ambiguous but WCAG 2.0 is 
      explicit. It's wise to look to WCAG 2.0 for direction 
      when the first draft is ambiguous.
      What does accessibility mean in Ireland exactly?
      One of the things this group could do is debate the 
      specific checkpoints it believes are most relevant in 
      providing access to the widest possible audience most of 
      the time. The WAI guidelines is exactly what it says on 
      the tin, a set of guidelines. So, this group could 
      provide assistance with the level of accessibility that 
      is desirable for each type of site owner (within reason). 
      For example, a high street bank may want to ensure its 
      site complies with more guidelines than say, a kid 
      selling obscure items from a bedroom.
      When is it ok to have an alternative site?
      It's advisable to have a very good business justification 
      when providing an accessible alternative to the main 
      site. Some people may feel discriminated against if they 
      feel like they're being treated differently without good 
      reason. This is especially true when the accessible 
      version isn't updated as often or if it doesn't provide 
      as many products as the main version. A good example of 
      an alternative that works well is www.jkrowling.com. Upon 
      entering the site we found issues that restricts access 
      to users without a mouse, however it's still a very good 
      example of an accessible flash site. It's the first I've 
      seen with an alternative version that's almost identical 
      to the original, and its in flash.
      CSS is highly recommended for layout for all of the good 
      reasons that everyone on this list is probably aware of. 
      However, this it's not mandatory, tables can be used for 
      layout if marked up correctly. Standards compliance is 
      black and white almost all of the time, so if anyone 
      thought this particular point was ambiguous, think again :)
      Many thanks for not falling asleep and I look forward to 
      your response to my rant.
            -----Original Message-----
            From: irl-dean-admin at list.eeng.dcu.ie 
            [mailto:irl-dean-admin at list.eeng.dcu.ie] On Behalf Of 
            Barry McMullin
            Sent: 27 March 2006 20:34
            To: irl-dean at list.eeng.dcu.ie
            Cc: mcmullin at eeng.dcu.ie
            Subject: Re: [Irl-dean] False Accessibility Developers
            On Mon, 27 Mar 2006, Eoin Campbell wrote:
            > We have developed a number of public sector websites 
            and made them as 
            > accessible as we believe possible, but other peoples 
            opinions may 
            > differ.  The following are areas where people have 
            complained about 
            > sites we developed, or we ourselves are not certain 
            what the best 
            > approach is.
            Eoin is quite right to point at the sometimes uncertain 
            or subjective nature of web accessibility evaluation.  
            This is a real problem.
            This is very current with me because we have just spent 
            an extended period, as part of the Support-EAM project, 
            minutely comparing three different "web accessibility 
            labelling" schemes currently in operation in three 
            different EU states.  The good news is that we found a 
            lot of commonality between them; however, we did also 
            find some notable divergences.  It is clear that even 
            among people who are really very competent in the area 
            there can still be honest disagreement.
            In principle, WCAG 2.0 should improve this situation - at 
            least some of the ambiguous or dated aspects of WCAG 1.0 
            are due to be addressed.  However ... WCAG 2.0 does still 
            seem to be some way away from finalisation.
            In the meantime, it might be no harm to have some "local"
            discussion here on irl-dean, just exchanging our own 
            opinions on what best practice (or best interpretation of 
            WCAG) would be in different practical situations. So, 
            with that in mind, and conscious that I'm going to differ 
            from some of the other reactions already posted, here's 
            my own tuppence worth on the specific questions 
      raised by Eoin:
            > 1. HTML vs. XHTML
            > Since MS-IE6 and Lynx don't support XHTML properly, we 
            still recommend 
            > HTML 4.01 Strict over XHTML 1.0 Strict for public 
            websites, for better 
            > backward compatibility.
            > Many believe using HTML in 2006 when XHTML is around 
            since 1999 is not 
            > accessible.
            This has been intensely debated back and forth several 
            times on the W3C wai-ig list (and probably elsewhere).  
            My own take is:
            - I have seen *no* documented accessibility benefit to using
              XHTML over HTML 4.
            - There *are* documented drawbacks, both accessibility and
              otherwise, to the hacks that are currently 
      commonly used to
              deploy XHTML at the moment. (They *can* be worked around
              ... but why bother?)
            - That said, *valid* code of just about any kind (XHTML or
              HTML) should trump invalid code of any kind (so 
      valid XHTML is
              clearly preferable to invalid HTML; but equally, 
      valid HTML is
              clearly preferable to invalid XHTML).
            - Of course, all this is independent of the use of 
      XHTML (or more
              generally XML) *internally* on the server-side.
            - Eamon mentioned that he was in favour of XHTML on 
      the basis
              that "... content can be parsed and 
      machine-processed as XML
              later on" but I think this is confusing the 
      HTML/XHTML issue
              either with the tag soup/valid code issue or with 
      the internal
              server representation/client side delivery representation
              issue. *Valid* HTML can be trivially transcoded 
      to XHTML at any
              time in the future if and when a scenario arises 
      where there
              actually is some reason for doing that.
            - In short, for the moment, the use of XHTML on the 
              seems to me to be mainly a fashion statement that 
      has little to
              do with accessibility or even technical need. So 
      I would be
              with Eoin, in advocated HTML 4.01 for delivery to the 
            client side.
            > 2. Strict vs. Transitional
            > Should accessible websites comply with the Strict 
            variant of the DTDs 
            > rather than transitional?
            > I think that, as a minimum, the HTML templates used to 
            maintain the 
            > site should, so that common boilerplate areas are as 
            accessible as 
            > possible.
            I would argue that, in marked contrast to the debate 
            between HTML and XHTML, there is a clear accessibility 
            benefit to preferring Strict over Transitional: many of 
            the things deprecated in Transitional are precisely to do 
            with accessibility.
            Eamon argued that sometimes "Transitional is right 
            because the page wants to do something Strict won't 
            allow"; but I'm finding it hard to come up with an 
            example. Could you be a bit more specific Eamon?
            Mind you, requiring a strict flavour of HTML does not *in 
            itself* guarantee that it will be used appropriately.  
            For example, strict might be said to encourage proper 
            separation of presentation from content; but it certainly 
            can't compel it.  It is perfectly possible to take a HTML 
            transitional page and mechanically replace many of the 
            deprecated presentational attributes with equivalent 
            style attributes - which may then allow it to conform to 
            HTML strict instead. But it is not one iota more 
            accessible for that.
            > 3. Image formats
            > Are GIF/JPEG images allowed instead of PNG?
            > Again, for maximum backward compatibility, I think yes, 
            but others 
            > disagree, since PNG is an open W3C standard, and 
            GIF/JPEG are not.
            A jesuitical reading of WCAG 1.0 checkpoint 11.1 would 
            probably say to prefer PNG; but, in my experience, the 
            practical impact of this particular choice on 
            accessibility is exactly zero.
            Accordingly I would say that even discussing this as an 
            "accessibility" issue is the sort of thing that gives 
            accessibility a bad name.
            > 4. Image alt text
            > Should every image have alt text?
            > I think not, but some people do.
            > (Especially those who only half-understand the WCAG 
            guidelines, in my
            > experience)
            Um - clarification please, Eoin?
            Do you mean "should every image have an alt *attribute*"? 
             If so, my answer is unequivocally *yes* it should (not 
            least because it is required for validity - but that, in 
            turn, was motivated by accessibility arguments).
            In the other hand, if you mean "should every image have a
            *non-empty* alt attribute", then I would certainly agree 
            that the answer is "no".  There are many cases where an 
            empty alt attribute is clearly the appropriate choice.  
            And I certainly see increasing numbers of "gratuitously" 
            non-empty alt attributes, which do seem to reflect 
            authors or designers who have heard of the technical 
            requirement for alt attributes but don't really 
            understand their practical implications for people with 
            > 5. Tables for layout
            > Some of our older sites use tables for layout of 
            navigation panels, 
            > but they linearise OK on browsers that don't 
      support tables.
            > Is this accessible or not? I think it is.
            Well, of course "accessible" isn't a binary property.  It 
            may not be a *severe* barrier, but it's not ideal either. 
             The catch is always that a user has to now guess whether 
            to attempt to use "real" table navigation or not.  If 
            they can be sure that all tables are for layout only and 
            can be safely linearised then that's fine.  But how are 
            they to find that out?  A slight abuse of the table 
            summary attribute might use it to say "layout table"
            - but if there are lots of these, and especially if they 
            are nested, this rapidly gets tedious.
            So, on the one hand I wouldn't get all that excited about 
            tables used for layout on legacy sites ( at least if not 
            nested, and they linearise sensibly); but I certainly 
            wouldn't want to see layout tables in any new development.
            >  6. Identifying link targets clearly One of the sites 
            we designed 
            > (www.teagasc.ie), has a left navigation panel where the 
            same word is 
            > used on links to 2 different target pages.
            > e.g. Environment (in the Advisory and Research 
            sublists).  This is 
            > explicitly at the request of the client, since that is 
            how their 
            > organisation is structured, and they don't want to use 
            different names 
            > for corresponding sections within different 
      divisions.  We put 
            > different text in the A/@TITLE attribute to try and 
            surmount this 
            > problem.  Does this satisfy the checkpoint? I would 
            argue yes in this 
            > case, although it is certainly debatable.
            Um ... I think it's "debatable" only in the sense that 
            some prominent automated checkers get it wrong.  There is 
            no explicit requirement in WCAG 1.0 that says that links 
            with the same link text must point at the same text.  
            This is stated *only* in the HTML techniques 
      document which says:
              If more than one link on a page shares the same 
      link text, all
              those links should point to the same resource. 
      Such consistency
              will help page design as well as accessibility.
            but which then adds, in the very next sentence:
              If two or more links refer to different targets 
      but share the
              same link text, distinguish the links by 
      specifying a different
              value for the "title" attribute of each A element.
            So there is absolutely no basis in WCAG for 
            preferentially requiring only the first of these techniques.
            As one addition to Eoin's list, I would mention the 
            practice of offering "text only" versions of a site as a 
            route to achieving accessibility.  There was a time when 
            this was positively fashionable, but I would have hoped 
            that understanding had moved on to embrace proper 
            "mainstreaming" and "universal design".
            Nonetheless, I am still seeing *new* site designs 
            prominently displaying a "text version" button as if it 
            is something to be proud of.  (In some cases this seems 
            to be on the basis of snake oil from some vendors of 
            tools to automatically generate such "text only" versions 
            - which are sold on the basis, explicit or implicit, that 
            this somehow magically resolves all accessibility issues 
            with arbitrarily designed sites...)
            Anyway, as I say, just my tuppence worth - I would be 
            very interested in other opinions.
            Best - Barry.
            Irl-dean mailing list
            Irl-dean at list.eeng.dcu.ie

More information about the CEUD-ICT mailing list