Re: Formal Objections (was: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1)

> On Mar 13, 2023, at 6:01 AM, John Foliot <john@foliot.ca> wrote:
> 
> Hi Gregg,
> 
> Here's how I see it. Organizations are struggling with 2 issues: drive-by conformance abuses, and the creation of busy work. 
> 
> This is caused *primarily* because testing tools are still reporting on test results based on including the automated 4.1.1 rule. The solution there (I will suggest) is to change the testing profile, as most of the tools I've seen and worked with allow just that: I can test for WCAG 2.0 A or 2.0 AA, or 2.1 A or 2.1 AA (etc.) 

    GV: agree. So we need to take 4.1.1 off the table or they can’t do that.   
> 
> So, if I want to remove 4.1.1 from the collection of automated tests, the answer is to load a different "profile" into the test tool. That profile HAS to be named something different than any of the other profiles, because it IS a different profile. Thus, the "slightly modified" rule set would be known as profile 2.X.1. Now organizations can adopt a new test profile into their test suites that eliminates the busy work impacting their dev and QA teams. I will assert this solves the first problem: "busy work".

    GV: as long as it is in the guidelines — we can’t change the evaluation profile or else it loses its face value with WCAG   
> 
> In terms of "reporting" conformance, organizations could still report as conforming against 2.X, because 2.X.1 and the attendant "note" state that 4.1.1 can be considered always passing. Using the backward compatibility principle, if you meet WCAG 2.X.1, then you *WOULD* also be meeting WCAG 2.X. I will suggest here that this will then solve the second problem: drive-by abuses

    GV: no —  a note cannot change an SC  so just adding a note has no effect on conformance or requirements at all.  In fact you can’t have a note that say anything contrary to an SC.  it can only explain what is already there. 

   
> 
> In Practice:
> While the ITI VPAT template is far from being universal, it IS a significant conformance reporting tool used by a large number of US and international organizations. Looking at the VPAT template, reporting against 4.1.1 could then look something like this:
> <image.png>
> (screen capture of the VPAT document showing SC 4.1.1 as "Supports" with the Remark "This requirement is considered met citing the evolution of the requirement documented in WCAG 2.X.1")

    GV: wellll   don’t get me started on VPATs.  They are not a way to report conformance.   They are a way to avoid reporting conformance.    In VPATs one never says that one meets an SC.  Only that they ’support’ it.    Which is carefully chosen and defined as NOT meaning that one conforms or meets the provision.    

> 
> This is but one example, but other means of addressing the drive-by abuses could include adding a statement to a websites' "Accessibility page" [sic], or similar ("Copyright 2021 - The ACME Widget company. This site meets the requirements of WCAG 2.X.1"). The point being, now dev and QA teams can use a test profile that eliminates the "busy work", and compliance and regulatory folks have a documented "normative" citation that asserts that they are "conforming" to a compliance requirement without the need for testing or 'explaining' why (for example) a duplicate ID in a section of code is NOT causing any harm to PwD. 

   GV: this helps if you area just reporting.  But many companies never want to report - for the same reason they want to use VPATs and not conformance statements.

ALSO it doesn’t help if the Purchase Order requires  2.0

> 
> To my way of thinking, this solves both types of problem: testing AND compliance (conformance) reporting, without trash-canning the current WCAG 2.X Recommendations. Personally, I have a very rigid interpretation of Standards: once officially published, they can evolve, but can never be "overwritten", and I will continue to object as strenuously as the W3C will allow against any suggestion to do that.

   GV: See above.  It doesn’t actually change anything.         They can’t be 'overwritten' but they can be revised.   There are thousands of standards that have been revised without being renumbered.    That is why regulations usually talk about a standard AND the date of the standards release.    
> 
> JF
> 
> On Sun, Mar 12, 2023 at 4:55 PM Gregg Vanderheiden <gregg@vanderheiden.us <mailto:gregg@vanderheiden.us>> wrote:
>> The    .1 approach doesnt help for people required to meet 2.0 
>> 
>> I fail to see the problems cited by the 'can’t do this"
>> 
>> If the right terminology is not being used — great. 
>> 
>> But before changing it to citing it — it would be good for those saying it won’t work to include pointers to the specific language that says something can’t be done. 
>> 
>> Also in doing that — it is important to distinguish between voluntary stds and ones that will be used in regulations. 
>> 
>> Best
>> 
>> g
>> 
>> 
>>> On Mar 9, 2023, at 9:18 AM, John Foliot <john@foliot.ca <mailto:john@foliot.ca>> wrote:
>>> 
>>> Hi Wendy, 
>>> 
>>> As I am one person currently suggesting a Formal Objection, let me say that I do understand your perspective. The problem is, right now, the working group is offering a binary choice: support the wonks or support the non-wonks [sic]. It is an unfair choice.
>>> 
>>> As a counter to the current proposal, I have offered a potential way forward that I believe supports the needs of both groups, and that is to "extend" (using the dot extension model) versions 2.0 and 2.1 to 2.0.1 and 2.1.1 versions respectively. I will argue this meets the needs of both groups more equitably as that too addresses "...for those that do need to reference 2.0 and 2.1 for conformance or legal reasons, they will understand that a change has occurred and what it means." - and in a far cleaner/precise way than what Matt noted as  “WCAG 2.0 (Second Edition)”
>>> 
>>> (As to depreciation versus obsolete; obsolete suggests "removal", whereas deprecation suggests "no longer required, but hey, it's still good practice" - which it is. This distinction can be clarified in the Note being associated to the proposed change)
>>> 
>>> When you say "I think it’s important to focus on the needs of our community" I actually agree - this means (logically) ALSO supporting the needs of the so-called process wonks (like me) in the community, who care about both the impact of standards, but how standards themselves are created and presented. It also means supporting the needs of the regulators, and of those practitioners who are reliant on translations of the current Recs, two constituencies I see being left behind with the current proposal.
>>> 
>>> And so, if my surfacing the risk of a Formal Objection today is distasteful to some at this time, I'll roll that back to "This is a decision I CANNOT live with". 
>>> I believe at the end of the day it amounts to essentially the same thing.
>>> 
>>> JF
>>> 
>>> On Thu, Mar 9, 2023 at 11:46 AM Reid, Wendy <wendy.reid@rakuten.com <mailto:wendy.reid@rakuten.com>> wrote:
>>>> +1
>>>> 
>>>>  
>>>> 
>>>> I do want to explain this and I hope it might offer some clarity to those in opposition or on the fence on this.
>>>> 
>>>>  
>>>> 
>>>> There is two ways to look at this change. One is from a strictly standards/process point of view. From that point of view, a more appropriate approach would be to leave 2.0 and 2.1 alone and mark 4.1.1 as deprecated in 2.2. It’s the most adherent to how standards are built, and for the standards wonks is the clearest communication of the change. The standards approach may accommodate an editorial note on previous versions at most.
>>>> 
>>>>  
>>>> 
>>>> The other point of view, and the one I am taking, is what would be most beneficial for the community at large, which includes far more people who are not standards wonks. That audience of people may or may not know what “deprecated” even means, or at least not in the context of standards. For this constituency, the proposed approach is much clearer, as it not only allows someone to read 2.2 and learn exactly what they need to know about WCAG, but for those that do need to reference 2.0 and 2.1 for conformance or legal reasons, they will understand that a change has occurred and what it means.
>>>> 
>>>>  
>>>> 
>>>> I understand the desire for precision, and I can be a standards wonk myself at the best of times, but I think it’s important to focus on the needs of our community over adhering to process for the sake of it. I understand how fraught this is, as someone who works on another specification with incredibly strict backwards compatibility requirements it is not easy to make these decisions and communicate them effectively.
>>>> 
>>>>  
>>>> 
>>>> On a personal note, the throwing around of threats to formally object to this change on what appears to solely be process grounds is in poor taste, and I really ask that those who are making those threats  consider the impact that has on the culture and tone of this group. We all care very strongly about the quality of this document and its impact on our community and the disability community at large, don’t make this harder than it needs to be.
>>>> 
>>>>  
>>>> 
>>>> Cheers,
>>>> 
>>>> Wendy
>>>> 
>>>>  
>>>> 
>>>> From: John Foliot <john@foliot.ca <mailto:john@foliot.ca>>
>>>> Date: Thursday, March 9, 2023 at 8:56 AM
>>>> To: Hakkinen, Mark T <mhakkinen@ets.org <mailto:mhakkinen@ets.org>>
>>>> Cc: John Foliot <john@foliot.ca <mailto:john@foliot.ca>>, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>, WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>>>> Subject: Re: [EXTERNAL] Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
>>>> 
>>>> [EXTERNAL] This message comes from an external organization.
>>>> 
>>>> Mark writes:
>>>> 
>>>> >  The concern is adequately addressed by deprecating (which I agree is the correct approach) in the latest, and member approved, specification.
>>>> 
>>>> +1. Mark is 100% correct, the proper way forward is deprecation, and not making the SC obsolete. This is indeed a well worn and common path for other W3C Recommendations.
>>>> 
>>>> Off list, it has been suggested to me that this proposed change will not have an impact on Section 508 or EN 301 549. It is important to remember however that while those two legislations do drive a significant amount of compliance behaviour, they are not the only external dependencies on WCAG 2.0/2.1 (ref: https://www.w3.org/WAI/policies/). Have any of these other legislated requirements been queried to see what (if any) impact this proposed change might have to those other dependencies?
>>>> 
>>>> Additionally, what will the impact be on officially translated versions of the Recommendation? (https://www.w3.org/WAI/standards-guidelines/wcag/translations/) Having an English version of WCAG 2.0 that does not align with the Polish Version <https://www.w3.org/Translations/WCAG21-pl/> (for example) very much feels like a problem simply waiting to happen.
>>>> 
>>>> What I do not see is a proposal for publishing a WCAG 2.0.1 / WCAG 2.1.1, which I will argue both addresses the needs and concerns around this SC in previously published versions of the Recommendation, while at the same time having a minimal impact on previously published versions of the Rec. The 'dot-extension' mechanism is flexible enough to accommodate this way forward, and it effectively and unambiguously delineates the two versions of either WCAG 2.0 or WCAG 2.1
>>>> 
>>>> 
>>>> I remain adamant however that I WILL file a Formal Objection if this Working Group continues to proceed with "overwriting" an existing Recommendation.
>>>> 
>>>> Respectfully,
>>>> 
>>>>  
>>>> 
>>>> JF
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> On Wed, Mar 8, 2023 at 9:44 PM Hakkinen, Mark T <mhakkinen@ets.org <mailto:mhakkinen@ets.org>> wrote:
>>>> 
>>>> Agreeing with John and Chaals.
>>>> 
>>>>  
>>>> 
>>>> Is there any precedent within W3C for changing an existing, versioned and published recommendation, agreed to previously in time by W3C membership?  Is it an errata? Don’t think so.  The concern is adequately addressed by deprecating (which I agree is the correct approach) in the latest, and member approved, specification.  SC 4.1.1 appeared relevant to us at the time, it was approved, and remains part of WCAG’s history.  Deprecate and move on in subsequent versions.
>>>> 
>>>>  
>>>> 
>>>> Mark
>>>> 
>>>>  
>>>> 
>>>> From: John Foliot <john@foliot.ca <mailto:john@foliot.ca>>
>>>> Date: Wednesday, March 8, 2023 at 3:20 PM
>>>> To: Siegman, Tzviya <tsiegman@wiley.com <mailto:tsiegman@wiley.com>>
>>>> Cc: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>, WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>>>> Subject: [EXTERNAL] Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
>>>> 
>>>> CAUTION: This email originated from outside of our organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>> 
>>>> Like Chaals, I'm also likely to make a Formal Objection to substantively changing a previously published W3C Recommendation. That is why we went with the dot extension model: 2.2 WILL BE different than 2.1 just as 2.1 was different than 2.0. Whether we like it or not, changing any of the WCAG versions after they have reached Rec Status may very well have knock-on impacts to legislated requirements around the world, and could have a detrimental (negative) reflection on the W3C writ large.
>>>> 
>>>>  
>>>> 
>>>> Despite Wilco's flawed argument, if you are conformant today to ALL of the WCAG 2.1 SC, then the path to meeting 2.2 conformance is to simply meet the new SC requirements (putting aside whether you previously did or did not meet 4.1.1).
>>>> 
>>>> 
>>>> I also struggle with invoking the term "Obsolete", and would much prefer to see "Deprecated" - the nuance is subtle but distinct.
>>>> 
>>>> JF
>>>> 
>>>>  
>>>> 
>>>> On Wed, Mar 8, 2023 at 3:01 PM Siegman, Tzviya <tsiegman@wiley.com <mailto:tsiegman@wiley.com>> wrote:
>>>> 
>>>> +1
>>>> 
>>>>  
>>>> 
>>>> Tzviya Siegman
>>>> 
>>>> Information Standards Principal
>>>> 
>>>> Wiley
>>>> 
>>>> 201-748-6884
>>>> 
>>>> tsiegman@wiley.com <mailto:tsiegman@wiley.com>
>>>>  
>>>> 
>>>> From: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> 
>>>> Sent: Wednesday, March 8, 2023 12:59 PM
>>>> To: WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>>>> Subject: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
>>>> Importance: High
>>>> 
>>>>  
>>>> 
>>>> ⛔
>>>> 
>>>> This is an external email. 
>>>> 
>>>> Call For Consensus — ends Friday Wed 15th at midday Boston time.
>>>> 
>>>>  
>>>> 
>>>> The group has discussed what to do with 4.1.1 Parsing in WCAG 2.0 & 2.1 now that it has been removed from WCAG 2.2.
>>>> 
>>>>  
>>>> 
>>>> From the discussion: 
>>>> 
>>>> https://www.w3.org/2023/03/07-ag-minutes#item10 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2023%2F03%2F07-ag-minutes*item10__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfez9VGJw%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BpgSNsLNWoan0MMpMhykdOtKiwpi%2BZ%2FO0d1HFjiyvyE%3D&reserved=0>
>>>>  
>>>> 
>>>> Following the same approach as WCAG 2.2 was the preferred approach, where the SC text would be removed and replaced with a note that says why it has been removed.
>>>> 
>>>>  
>>>> 
>>>> The specific changes are detailed in these two pull requests:
>>>> 
>>>> https://github.com/w3c/wcag/pull/3093 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F3093__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmdMiSXedg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dc3IcVKEtDoNcN3Qrmn7UZGAw1NH2r628%2FGJSrnuHSk%3D&reserved=0> 
>>>> 
>>>> https://github.com/w3c/wcag/pull/3094 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F3094__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcNvvv_-g%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uRxuptZeSVTF%2BSi5ANWPNTAH6JDNcgP4Wl8svIbIBAI%3D&reserved=0>
>>>>  
>>>> 
>>>> Survey results: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq23 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F35422%2Fwcag22-misc5%2Fresults*xq23__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmewMpiCqg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R6V9q0sWNGbw0IWJITDyGWlKLO6tYxuolpmiiBkx99s%3D&reserved=0> 
>>>> 
>>>>  
>>>> 
>>>> If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.
>>>> 
>>>>  
>>>> 
>>>> Assuming the group agrees to this change, there is likely to be a public review before we can re-publish WCAG 2.0 & 2.1. 
>>>> 
>>>> https://www.w3.org/2021/Process-20211102/#last-call-review <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2021%2FProcess-20211102%2F*last-call-review__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcpGrAkRg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mjWLAtijjUxjfswpSIZbcwgsdFrKfUhVRZ7XOr7AR%2Bo%3D&reserved=0>
>>>>  
>>>> 
>>>> Kind regards,
>>>> 
>>>>  
>>>> 
>>>> -Alastair
>>>> 
>>>>  
>>>> 
>>>> -- 
>>>> 
>>>>  
>>>> 
>>>> @alastc / www.nomensa.com <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.nomensa.com__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfGTPcEDg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8MisvXGtatsJL9voEZFfcnztYchSFEop7St19rZEGj4%3D&reserved=0>
>>>> The contents of this email and any attachments are confidential and intended only for the person or entity to whom it is addressed. If you are not the intended recipient, any use, review, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this message in error, please immediately notify the sender and permanently delete all copies of the email and any attachments.
>>>> Click here for translations of this disclaimer. <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.wiley.com%2Femail-disclaimers&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=edTrghDOjweQNT2Lt7BYF0khbYofSMyNPyetmPx8CTI%3D&reserved=0>
>>>> 
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> John Foliot | 
>>>> Senior Industry Specialist, Digital Accessibility | 
>>>> W3C Accessibility Standards Contributor |
>>>> 
>>>> "I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"
>>>> 
>>>>  
>>>> 
>>>> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
>>>> 
>>>>  
>>>> 
>>>> Thank you for your compliance.
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> --
>>>> 
>>>> John Foliot | 
>>>> Senior Industry Specialist, Digital Accessibility | 
>>>> W3C Accessibility Standards Contributor |
>>>> 
>>>> "I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"
>>>> 
>>> 
>>> 
>>> -- 
>>> John Foliot | 
>>> Senior Industry Specialist, Digital Accessibility | 
>>> W3C Accessibility Standards Contributor |
>>> 
>>> "I made this so long because I did not have time to make it shorter." - Pascal
>>> "links go places, buttons do things"
>> 
> 
> 
> -- 
> John Foliot | 
> Senior Industry Specialist, Digital Accessibility | 
> W3C Accessibility Standards Contributor |
> 
> "I made this so long because I did not have time to make it shorter." - Pascal
> "links go places, buttons do things"