- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Fri, 14 Aug 2009 10:54:39 +0200
- To: w3c-wai-ig@w3.org
Hi W Reagan, At 08:05 14/08/2009, W Reagan wrote: >I recently discovered the corresponding rule at WCAG 2.0; SVR2. The >difference between SVR2 and what the security team has set up is to >cause certain users a general failure, even if the page was AAA accessible. Using IP blocking to prevent access to a complete site has nothing to do with WCAG. It also has nothing to do with technique SVR2 <http://www.w3.org/TR/WCAG20-TECHS/SVR2.html>. If a user's IP address is blocked for the whole site, he can't reach the site. The question whether the site is accessible or not (in the sense of "accessible for people with disabilities") then becomes a meaningless question for that user. You can check if your site meets WCAG 2 without knowing the ranges of IP addresses that are being blocked. These issues are independent of each other. (Except if the security team decided to allow access to a non-conforming part of the website and block access to the conforming part, but I don't see why they would do that.) >Some users are getting a Forbidden error message, while others users >are welcome to the site.. WCAG is not about comparing one person's access rights versus another's. It's about accessibility for people who can actually *reach* the site, and then use it regardless of disabilities. >The security team implemented an IP blocking address in some parts >of the U.S., all of Asia, and all of Europe. So only specific >regions in the U.S., all of Asia, and all of Europe have been a >security risk to our site. Therefore, we are using deny IP address, >and deny by domain. That issue is irrelevant to this list. >What can the security team do to maintain security while I mantain >accessibility? These issues are orthogonal to each other, unless the security team enforces methods that make it harder for persons with disabilities to use the site (for example CAPTCHAs). However, until then, your security team can focus on security, while you focus on accessibility. Best regards, Christophe >--- On Wed, 8/12/09, W Reagan <wreagan1@yahoo.com> wrote: > >From: W Reagan <wreagan1@yahoo.com> >Subject: Re: Htacces and WCAG 2 >To: w3c-wai-ig@w3.org >Date: Wednesday, August 12, 2009, 5:16 PM > >Ben, if we denied /googlemail.com you could not see our site. This >is the type of information our security team has set up. Does it >conflict with any accessibility standards? > >As I mentioned earlier, our security team keeps track of users by IP >address and also check out other sites where our domain is posted, >but should not be. > >What can we do to maintain security while maintaing accessibility > >What criteria(s) are in conflict, if any? > >--- On Wed, 8/12/09, Benjamin Hawkes-Lewis ><bhawkeslewis@googlemail.com> wrote: > >From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> >Subject: Re: Htacces and WCAG 2 >To: "W Reagan" <wreagan1@yahoo.com> >Cc: w3c-wai-ig@w3.org >Date: Wednesday, August 12, 2009, 4:32 PM > >On 12/08/2009 15:39, W Reagan wrote: >[snip irrelevant detail] > > We need to protect our security and maintain accessibility. > >You're asking us for help. But you need to help us help you. > >Please answer my simple questions: > >1. "[Do you] have special reason to think that blocking by IP or >referrer would reduce the accessibility of your website to people >with disabilities?" > >2. "Which of the success criteria listed at ><http://www.w3.org/TR/WCAG20/>http://www.w3.org/TR/WCAG20/ do you >think might conflict with blocking HTTP requests by IP or referrer?" > >It's not obvious why you would think this, so please explain your >thought process. > >-- >Benjamin Hawkes-Lewis > > -- Christophe Strobbe K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on Document Architectures Kasteelpark Arenberg 10 bus 2442 B-3001 Leuven-Heverlee BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ --- "Better products and services through end-user empowerment" http://www.usem-net.eu/ --- Please don't invite me to LinkedIn, Facebook, Quechup or other "social networks". You may have agreed to their "privacy policy", but I haven't.
Received on Friday, 14 August 2009 08:55:46 UTC