- From: Gez Lemon <gez.lemon@gmail.com>
- Date: Tue, 31 Jan 2006 23:39:21 +0000
- To: "Li, Alex" <alex.li@sap.com>
- Cc: public-wcag-teama@w3.org
Hi Alex, Thank you for the detailed response. > I think the way to go about resolving this is to determine first if user > trigger of opening multiple windows is allowed. I'm not sure I follow you, here. The user can open as many windows as they wish, as it's their user agent, and they're free to use it how they like. The problem is when content authors make decisions on behalf of their users. > I think all of us would > agree that a user triggered of opening multiple windows actually passes > 3.2.5 when such event is expected. I don't agree. > Keyword here is expected. That's the exactly point - I never expect anyone else to make decisions on my behalf about how I use my software. > A concrete example is (You may skip to next paragraph if you don't need > a business example.) I did read this example, to try and get a better understanding of where you're coming from. Correct me if I'm mistaken, but this sounds to me as though you're saying, "This is how some of our systems work, and we say they're accessible". This guideline is tied to the principle of understandability, and predicted and expected behaviour has to play a significant part in that. I wouldn't expect any program I started to suddenly spawn lots of windows - it's indicative that the system hasn't been designed correctly. What's wrong with the traditional software engineering approach of logging everything, and making the reports available at the user's request? Just to put all this in context - I have no problem with the concept of a settings page, where users can decide how they want the system to run. By default, no automatic spawning of popup windows, but configurable to allow such actions. At least with that kind of system, the result is expected behaviour as it was chosen by the user. > Re Meta refresh-The definition of change of context requires a change of > meaning. A page refresh does not always change the meaning of the > content. That is why meta refresh in and of itself does not necessarily > meet the level of failure by change of context. If only a portion of a page is being updated, I think that AJAX or AHAH would be more appropriate that a meta refresh, although I'm not sure how well AT works with these techniques. Theoretically, they should know which parts of the DOM have changed, but they're traditionally pretty bad at this. The problem I have with meta refresh is that it's mainly used in an annoying way, and because of this, lots of people set up their browsers not to allow meta refreshes. If a particular website or web application relies on this, it means that people will have to enable an annoying function just to be able to use the site in question, which then leaves them exposed when they go elsewhere. Expecting people to adjust their settings seems a bit harsh. Best regards, Gez -- _____________________________ Supplement your vitamins http://juicystudio.com
Received on Tuesday, 31 January 2006 23:39:25 UTC