cookies and WCAG checkpoint 6.3
Okay, got a bit of a tricky question.
Thinking about WCAG 6.3, do cookies count as programmatic objects?
For ref 6.3 is:
| Quote: |
| 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1] |
If a site is unusable because cookies are switched off, then does it fail this checkpoint?
(I'm not talking about just styleswitching or font resizing here - I'm talking about whole site failure)
Share: 
...like this forum you mean?
...I would say - yes - it is a WAI A failure.
but a tricky one, so many sites rely on cookies for login and session management and the like...
...can open, worms everywhere...
http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_8.htm#mdiv57
Share:
hehe - I wasn't talking about this forum! 
I'm thinking it is as well .. the argument was over whether they are 'programmatic objects' or not.
Share:
well, to my mind, if a script or applet relies on being able to right or read cookies in order to say, access a website, then that cookie is part of the program, be it it's output or input - if the script cannot run without the cookie then an alternative should be provided.http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_8.htm#mdiv57
Share:
...This is a VERY strict interpretation of the point though...http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_8.htm#mdiv57
Share:
But say you are using a cookie to maintain state in a server side application, which is AFAIK their most common usage.
Share:
Why not use a session variable instead?
If we're going to agree that cookies are programmatic objects and the site doesn't work without them then it's still going to fail 6.3, no matter what their actual function is. No?
Share:
| orchid wrote: |
| Why not use a session variable instead?
If we're going to agree that cookies are programmatic objects and the site doesn't work without them then it's still going to fail 6.3, no matter what their actual function is. No? |
Session variables store the session ID in a cookie. You can get around this by passing the session ID back and forth in URLs instead, but it's painful.
Share:
| Quote: |
| Session variables store the session ID in a cookie. You can get around this by passing the session ID back and forth in URLs instead, but it's painful. |
Ooh - I didn't know that. But at least you have got a fallback there that doesn't involve cookies.
So how many sites out there claiming to be AA or even A compliant are reliant on cookies for their functionality?
Share:
| orchid wrote: |
| Ooh - I didn't know that. But at least you have got a fallback there that doesn't involve cookies.
So how many sites out there claiming to be AA or even A compliant are reliant on cookies for their functionality? |
This one, which I built, for a start:
National Maritime Museum Collections
It uses session variables quite extensively.
Share:
I was thinking about this, and I would say that cookies are not covered by the point in question when used from the server side since they are not part of the presented (x)HTML document or used as a client side resource.
The transfer of cookies is handled within the headers of the HTTP transaction by the UA. It would almost be the same as saying that an application that makes use and relies on content-type not complying.
At some point I guess a boundery has to be drawn. There is no guideline that says that a browser must support ECMA Script or Java, these are options, but I am unaware of a browser that doesn't support cookies.
Share:
| Richard Conyard wrote: |
| ...but I am unaware of a browser that doesn't support cookies. |
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
| JackP wrote: | ||
|
Then you'll probably find you can't use quite a lot of the web on those PCs.
Cookies have been part of HTTP for over a decade, as a mechanism to maintain state between client and server. I don't think it's unreasonable to expect that a web browser will accept cookies from the domain of the page that it's browsing.
Googlebot doesn't accept cookies, so we try not to use cookies on pages that we want to be indexed in Google.
Share:
true - but with security enhancements even those sites now have cookies enabled most of the time.
In web dev perhaps the hardest cross over to learn from traditional development is that of state management since http is a single state transaction. Session management through cookies is pretty much the only feasible way to manage state ( session in URI = messy, session through form variables just as messy), so it's a bit of a toughie.
Share: