cookies and WCAG checkpoint 6.3
| cez wrote: | ||
Enabled or disabled? |
Enabled, since you'll have turned them off because using them made life difficult for you. Just as you turned off Javascript because it prevented you from using the page.
Share: 
| orchid wrote: |
I think this is more a case of showing how old the WCAG guidelines are, and how dangerous it is to slavishly adhere to them.  |
...i just thought that needed repeating...
http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_8.htm#mdiv57
Share:
| eatyourgreens wrote: |
|
Using Javascript may render content invisible to screenreaders. Or it may require the use of a mouse in order to use a page. So it does raise barriers for disabled people. What disability prevents you from accessing a page if cookies are enabled? |
Well, the reasons why you disable a feature of your browser aren't at issue if we're discussing the letter of the guideline. The fact is that it is disabled and the site doesn't work.
But I totally agree, a pragmatic approach is the only way to go.
Share:
| orchid wrote: | ||
Well, the reasons why you disable a feature of your browser aren't at issue if we're discussing the letter of the guideline. The fact is that it is disabled and the site doesn't work. But I totally agree, a pragmatic approach is the only way to go. |
I agree, but sometimes people discuss the nitpicky details of the guidelines whilst completely failing to quote the very first sentence of WCAG:
| WCAG wrote: |
| These guidelines explain how to make Web content accessible to people with disabilities. |
Share:
| cez wrote: |
| HTTP Authentication, so far as I am aware. So how do you propose an application such as a shopping cart works when session cookies are disabled (or not supported)? |
Why would this not fail for the same reason as a cookie?
Share:
| Richard Conyard wrote: | ||
Why would this not fail for the same reason as a cookie? |
Good point. I guess the only difference is that your browser doesn't offer you the option to disable HTTP authentication.
Share:
| Richard Conyard wrote: | ||
Why would this not fail for the same reason as a cookie? |
Because it is a host header.. though if I am missing your point, please clarify.
Cez
Share:
| cez wrote: |
|
Because it is a host header.. though if I am missing your point, please clarify. |
A cookie is a header too.
From the server:
| Code: |
| HTTP/1.1 200 OK
Set-Cookie: name=value Content-type: text/html |
From the browser:
| Code: |
| GET /spec.html HTTP/1.1
Cookie: name=value Accept: */* |
Share:
Yes, but the cookie is stored (or not stored) in the UA. I was unaware that you can block an authenticated header.Cez
Share:
| cez wrote: |
| Yes, but the cookie is stored (or not stored) in the UA. I was unaware that you can block an authenticated header. |
If you tick the box to remember it so is the username and password.
Share:
| cez wrote: |
| Yes, but the cookie is stored (or not stored) in the UA. I was unaware that you can block an authenticated header. |
Surely this is a failing of UAs - not offering disabled users the option to disable a feature which might present accessibility problems.
Share:
| Richard Conyard wrote: | ||
If you tick the box to remember it so is the username and password. |
I didn't think that blocks authentication; it removes the need to repeatedly enter the username and password when asked to authenticate again. The authentication takes place internally, within the UA. The UA knows whether it has been authenticated or not. If nothing has happened to remove authentication (i.e. clearing the authenticated headers, or closing the UA), then the UA will not repeat the request to the user.
Just to clarify, I am talking about UA authentication dialogues, not a web form.
| eatyourgreens wrote: |
| Surely this is a failing of UAs - not offering disabled users the option to disable a feature which might present accessibility problems. |
No, you can select cancel when the UA opens the dialogue requesting u & p. That will cancel it, which means that the user can choose not to respond to the request.
[added] if there are UAs that cannot respond to authentication requests, then yes it is a problem with the UA. It is a function of the client-server model though, so if there are, then I shouldn't imagine that such UAs are of much use, if they exist.
Cez
Share:
| cez wrote: |
| I didn't think that blocks authentication; it removes the need to repeatedly enter the username and password when asked to authenticate again. The authentication takes place internally, within the UA. The UA knows whether it has been authenticated or not. If nothing has happened to remove authentication (i.e. clearing the authenticated headers, or closing the UA), then the UA will not repeat the request to the user. |
A small point - the authentication takes place on the web server, not the UA. Your username and password are passed back and forth as plaintext in the HTTP headers (for basic authentication). That's how the UA identifies itself to the server on subsequent requests.
Obviously, your username and password are available to anyone who sniffs the HTTP requests and responses.
| cez wrote: | ||
No, you can select cancel when the UA opens the dialogue requesting u & p. That will cancel it, which means that the user can choose not to respond to the request. |
Yes, and how is content being inaccessible because HTTP authentication is declined by the user different from content being inaccessible because cookies are declined by the user? If one fails 6.3, so does the other.
Share:
| eatyourgreens wrote: | ||
|
I agree, but sometimes people discuss the nitpicky details of the guidelines whilst completely failing to quote the very first sentence of WCAG:
|
Good point! I like it.
It was just pointed out to me that disabled users might use Assistive Technology - specialist browsers - that don't ship with cookie support. Which would then draw this issue back into the auspices of WCAG. No?
Share:
| eatyourgreens wrote: |
| A small point - the authentication takes place on the web server, not the UA. Your username and password are passed back and forth as plaintext in the HTTP headers (for basic authentication). That's how the UA identifies itself to the server on subsequent requests. |
Sorry, I should have worded that better.
| eatyourgreens wrote: |
|
Obviously, your username and password are available to anyone who sniffs the HTTP requests and responses. |
Only if unencrypted. Everything is detectable across any unencrypted connection, so I'm not sure what your point is there.
| eatyourgreens wrote: |
| Yes, and how is content being inaccessible because HTTP authentication is declined by the user different from content being inaccessible because cookies are declined by the user? If one fails 6.3, so does the other. |
I think that you are going overboard here. Access restriction is essential under certain conditions. If the user chooses not to authenticate themselves, then that is a choice to not view the content. It is not different to turning around at the door of a venue and leaving because they asked you to pay, but you don't want to. That does not mean that the venue is inaccessible because of any disability, and similarly, it doesn't mean that a site is, IMO.
Cez
Last edited by cez on 01 Sep 2006 01:42 pm; edited 2 times in total
Share: