11 replies [Last post]
Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 14 years 10 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Oh how I hate persistent cookies or any cookies for that matter on test sites. I can understand those in Site Checks, provided the site really is ready. But why, are there cookies on sites members are asked to look at which are merely the bare bones of:

<head>
<body>
<stomach><p>read JS - full of cookies</p>
<content><p>under construction! need help</p>
</content>
</stomach>
</body>
</head>

Must go - computer running v.e.r.y slow - need to clear temp files and goodness knows what else. Then switch off cookies in my browsers and be very selective which test sites I allow to place cookies.

Seriously though - am I alone in this view? Or am I just being a curmudgeonly spoilsport? [-(

Lorraine

Tags:
Tony
Tony's picture
Offline
Moderator
Brisbane
Last seen: 2 days 18 hours ago
Brisbane
Timezone: GMT+10
Joined: 2003-03-12
Posts: 5343
Points: 2964

Cookies

Hi Lorraine,
Actually I think cookies can be very useful on web sites and like JavaScript I wish everyone had it enabled.
Some things would be so much harder without cookies, for example I use cookies on www.appcreator.com to make sure I only collect stats from each visitor once.
They are also used a lot in style sheet switching and storing user preferences.

I can see your point for test sites, if you have your browser settings set to warn you about cookies, but what information are you worried about the sites storing.
Why not just accept cookies or are you only worried about the space they take up?

Cookie security scares

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 14 years 10 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Cookies

Hello, Tony
I agree about live sites, with the proviso evident in my second para. My issue is with test sites and it's not to do with security issues (of which, I know, there are none). It's to do with the necessity of cookies when sites are in the very early stages of development and with space issues, particularly on my office computer (poor, impoverished charity that we are). More importantly, it's to do with upwards compatibility and what could happen to the scripts when a site is served properly in XHTML 1.1 as application/xhtml+xml.

Finally, although this could muddy the waters a bit, it's to do with accessibility.
http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts

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]

Scripts need a <no-script> alternative to reach the lowest level of accessibility. Many people with disabilities will disable scripts in browsers that support them - often it goes to the usability of their assistive technology. Some disabled people (I'm thinking particularly of the totally blind) don't need multi-function browsers and use very basic browsers that don't support scripts.

So site traffic, visitor stats etc would not include visits (or rather attempted visits) by a significant minority of people. Scripts for stylesheet switching and user preferences would need to sniff out and advise this significant minority what they are missing or tell them they have to turn on cookies and Javascript to take advantage of the feature. That is, if you want an accessible site - many do not, but it can't be too long now before Disability legislation in many countries, will make them think again.

And, as for re-directs and accessibility, I don't even want to go there. Evil

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 41 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Cookies

I know what your getting at Lorraine as a example of what tends to irritate me is checking someones site by request in IE only to find I'm being prompted to alow an activeX control Evil which I do not like at the best of times and only allow when I know exactly what's going on
examination of said site shows a navigation ul list nested in an 'object'
tag :? for no reason that I could determine. What worries me are people that are not really aware of what their doing and why and I agree for the purposes of requesting help and checks they should keep these items to a minimum.

Although I agree with Tony that cookies are extremely useful and that there is far too much paranoia surrounding their use and that life would be easier if one didn't need to be concerned that your benign cookie might be blocked, I do tend to keep permissions very tight and have a lot of layered security, with sites such as csscreator where I know what their using cookies for I allow them trusted site status and only ever allow session and 1st party cookies, third party cookies are blocked as a matter of course and normally any other sites have to prompt for acceptance which I deny rather than have to trawl through them deleting them one by one.
Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Tony
Tony's picture
Offline
Moderator
Brisbane
Last seen: 2 days 18 hours ago
Brisbane
Timezone: GMT+10
Joined: 2003-03-12
Posts: 5343
Points: 2964

Cookies

Hi Lorraine,
I'd like to clear up a couple of things that could be misunderstood, specifically related to http://www.appcreator.com as I can't speak for every site Smile

Quote:
So site traffic, visitor stats etc would not include visits (or rather attempted visits) by a significant minority of people.
People with cookies disabled can still visit the site and although it is not the most accessible site on the web it still gets it's content across. Having the cookies on or off makes no difference to the content at all only the way the stats are calculated, otherwise the stats would be leaning to far towards whatever browser OS I use Cool.
I think that site is about 4 years old now and I really have don't remember the code details and don't want to dig them out but the stats still capture stats from users with cookies disabled.

Quote:
Scripts for stylesheet switching and user preferences would need to sniff out and advise this significant minority what they are missing or tell them they have to turn on cookies and Javascript to take advantage of the feature.
Stylesheet switching is adding features to the site that may help accessibility.
If a visitor can't access a style switcher he should still be able to access the content, just wont be able to see the different themes etc. Most users that can't access stylesheet switchers would probably prefer not to worry about them as long as they don't mess up the content.

The move now days is to have the added features degrade gracefully if they are not supported, that means if the feature is not supported make sure it doesn't mess up the content or provide errors.
CSS is a classic example of graceful degrading, if a browser doesn't support css then the text content should be still accessible.

Quote:
That is, if you want an accessible site - many do not, but it can't be too long now before Disability legislation in many countries, will make them think again.
Your right many people don't care about accessibility and really on the web accessibility is only a baby, actually the web is only a baby as well.

Lets take an example, maybe a little extreme, but still an example.
If a visitor is using lynx a text only browser to view your site can you possibly make all the features accessible. Sure you can do your best to provide alt attributes for images but they will never get to see that beautiful background.
So would that mean we have to remove all color and images from our sites incase someone comes along with lynx and can't see the pretty colors.
Of course not, the content of the site is still accessible or should be the colors and backgrounds are just added features that are there if your browser supports them and don't mess up the content when your browser doesn't.
Much like a style switcher that uses JavaScript and Cookies, just an added feature that may improve accessibility to some users.

By the way I'm about to release a User Preference Script that uses JavaScript and Cookies Smile

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 14 years 10 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Cookies

Quote:
People with cookies disabled can still visit the site

Agreed.
I did not imply sites that set cookies are not accessible when scripts are disabled. Scripts that set cookies do not include information for the visitor but information about visitor preferences and useful stats for site owners. The reference to attempted visits is about people who don't want a cookie for whatever reason and merely go away without entering the site. They may be wrong, but there we are.

What about those scripts that do include information for site visitors? A facile example, I know, but the ubiquitous "today's date and time right down to constantly ticking seconds" comes to mind. Also "you are visitor number 984,124".(Yeah right.) That's information that is not accessible without equivalent textual information through a no-script version. Similarly applets and other objects should have an alternative description not only to 'degrade gracefully' but also to be accessible to people with serious sight loss who use up-to-date browsers.

Quote:
still capture stats from users with cookies disabled

Do you *need* to set cookies then or have I missed another use such as a styleswitcher? Can't be user preferences, yet, which you are about to release. Sorry about that. Smile

Quote:
If a visitor is using lynx a text only browser to view your site can you possibly make all the features accessible. Sure you can do your best to provide alt attributes for images but they will never get to see that beautiful background.

It's difficult finding examples and drawing analogies isn't it? But one has to assume that someone using a text-only browser knows it 'does exactly what it says on the tin" - text-only. It's also reasonable to assume that visitors who could benefit from styleswitching/user preferences will enable scripts and cookies to take advantage of these features, particularly, if they don't already know they can customise their browsers so that their preferences will be available on all the sites they visit, not just the current one.

The real point is that no information (not just the text in #contents and #navbar etc) available to sighted visitors should be denied to those who cannot access all of it. Just like the accessibility of premises. In the Uk the Disability Discrimination Act (DDA) insofar as it relates to buildings has recently come into effect. Access to public buildings cannot be denied to anyone. So an alternative way has to be provided for people who cannot use the pretty, architectural, beautifully designed steps, stairs and escalators to get into the building or through doors that are too narrow for a wheelchair. The DDA for accessibility of information (including websites) has been in effect since 1999, So even after 6 years UK-based sites are still at the foetus stage, let alone baby.

I knew mention of accessibility would muddy the waters, but my issue is still with the use of cookies on fledgling sites in the forum.

Tony
Tony's picture
Offline
Moderator
Brisbane
Last seen: 2 days 18 hours ago
Brisbane
Timezone: GMT+10
Joined: 2003-03-12
Posts: 5343
Points: 2964

Cookies

Hi Lorraine,
I agree with what you are saying I just think many people get too caught up in accessibility issues based around javaScript and cookies being evil.

Quote:
Do you *need* to set cookies then or have I missed another use such as a styleswitcher?
No, I choose to set cookies because in this case it helps me with part of the stats. I could find another method to achieve what I want but really it's not worth the effort to me and would have no benefit to anyone else.
Actually I did have a PHP style switcher long ago on www.appcreator.com but removed it because the styles were really crappy, I have enough trouble coming up with one design Smile

Really the accessibility issue ( sorry it's more interesting then cookies) comes down to definitions of content.
If to be accessible your content must be available to everyone, do you consider a style switcher or an applet of say a water effect, content or an added feature.
Hopefully no one visits a site because it has a style switcher, they should visit the site for the content.

I understand your point about providing alternative content but believe, at times it can do more harm then good.
Really it should depend on the object being replaced, just like providing alt descriptions on spacer images is pointless.
I know we a treading a fine line here where there is no perfect answer, well none that will satisfy me anyway Wink
People will have differing opinions of whats right and wrong we must accept that and move on.

Cookies also need testing, but not when requesting a CSS site check Smile

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 14 years 10 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Cookies

Quote:
javaScript and cookies being evil

Not evil, but it's not wrong to question the necessity of some of them IMO.

Quote:
do you consider a style switcher or an applet of say a water effect, content or an added feature.

Styleswitcher - feature to give access to content. Applet of a water effect, if it is used as eye-candy, - feature, but there's no harm in adding alt text to the image. If the water effect is meant to convey information, then I would consider it necessary to add <alt> text, or probably, more correctly <title> or <longdesc>.

Quote:
Really the accessibility issue ( sorry it's more interesting then cookies) comes down to definitions of content.

To say nothing of issues surrounding: how people with reduced motor skills, or no sight, who have to use the keyboard (or a specialised pointing device, like a head stick or switch) will be able to navigate through the site. Then there's access keys, breadcrumb trails whether and when to use them - what will they sound like in screen-readers, colour combinations for people with various forms of colour-blindness, clear concise copy writing for people with dyslexia and learning difficulties, semantic mark-up of <h*>, the use of "blinking" text and images which can affect people with epilepsy. I won't go on but there's a lot more to it than content.

Quote:
just like providing alt descriptions on spacer images is pointless.

Agree. Layout-only tables are generally pointless, anyway, if css is used as intended. Tables for tabular data, shouldn't need them.

Quote:
People will have differing opinions of whats right and wrong we must accept that and move on.

But those who truly want to produce an accessible site will turn to the guidelines, recommendations, help on techniques etc from the Web Accessibility Initiative, accept those, try to work within them and help to move the Web *forward*.
http://www.w3.org/WAI/

Quote:
Cookies also need testing, but not when requesting a CSS site check

Couldn't agree more. I guess it all comes down to members not reading, not understanding, or discounting your instructions on the Beginners Forum Announcement.
Quote:
Techniques to solve problems:
a. Make a copy of the page so you don't mess up all your hard work.
b. Simplify the page as much as you can remove unrelated elements.
c. Isolate the problem by commenting out sections of the CSS.
d. Use borders or background colors to show positions of the elements your working with.

"unrelated elements" - huh? doh! - add any or all of the emoticons.

Tony
Tony's picture
Offline
Moderator
Brisbane
Last seen: 2 days 18 hours ago
Brisbane
Timezone: GMT+10
Joined: 2003-03-12
Posts: 5343
Points: 2964

Cookies

Hi Lorraine,

Quote:
But those who truly want to produce an accessible site will turn to the guidelines, recommendations, help on techniques etc from the Web Accessibility Initiative, accept those, try to work within them and help to move the Web *forward*.
http://www.w3.org/WAI/
Of course you are correct, but keep in mind that recommendations are made to be broken Wink
I sometimes have a problem with blindly following rules and recommendations.
Although the recommendations or guidelines try to encourage best practices they can and will change.
A good example is what we both have agreed on regarding alt text for spacers etc.
In the Web Content Accessibility Guidelines 1.0
Quote:
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Then in Web Content Accessibility Guidelines 2.0 still a working draft.
Quote:
If the non-text content does not provide functionality or convey information, then mark the non-text content so that it may be ignored. Ask, "Will it be distracting? Is the non-text content necessary to understand the rest of the content? Is there another way to create the effect?"

Looks like they are heading in the right direction at least.
10.2 Spacer images

They are still undecided on noscript

16.1 Text alternatives for scripts

Quote:
Editorial Note: It is unclear whether noscript should always be required, even if script failure does not present an accessibility problem, such as with most image rollovers. As a "technology not supported" technique this depends on the outcome of our discussion on baseline.

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 14 years 10 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Cookies

Yep - the goalposts are ever changing.

If the working draft for version 2.0 runs true to form, it will be quite some time before it it becomes 'normative'. The working group are very responsive (perhaps too responsive) to public comment. Looking at some of those public comments - the normative could be v. different to the draft.

If you absolutely have to produce accessible sites (as I do), it's a real headache keeping up with the changes. I am keeping an eye on 2.0 (no pun intended) and developing a sort of mirror site for my own charity, I change it continually based on what I judge will be in 2.0 eventually. Now that's great fun Wink On the whole, however, particularly on sites I develop, pro bono, for other charities, I stick with the recommendations and guidelines already in place.

Quote:
I sometimes have a problem with blindly following rules and recommendations.

Shame on you Shock But then you do have the redoubtable (and ever-patient) David and Hugo with their DTD and HTML/CSS validation sigs.

Monty
Offline
newbie
Last seen: 13 years 3 weeks ago
Timezone: GMT-5
Joined: 2005-01-27
Posts: 1
Points: 0

Cookies

Hi folks,

I want to provide users with client-side font size switching (just that) but without using persistent cookies. I realize that the visitor will revert back to the default size with each new visit but for a number of technical and bureaucratic reasons, I can't use server-side code or persistent cookies. All my <H*> styles are set as percentages and the default <p> size is 100%. I'm hoping to add the font change function in the footer of my page template. Thanks for any advice.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 5 years 41 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Cookies

Monty,
You should really have started off a new topic rather than tagging on the end of an old one!

Regards the question, what about JavaScript as a possible client side solution ?it may be worth having a look at Tony's (forum leader) latest project the Dynamic User Preference Script

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me