- From: <noreply@w3.org>
- Date: Sun, 21 Jun 2015 23:41:38 +0000
- To: public-comments-wcag20@w3.org
Name: Nick Levinson Email: Nick_Levinson@yahoo.com Affiliation: none Document: W2 Item Number: Guideline 2.2: Provide users with disabilities enough time to read... Part of Item: Comment Type: technical Summary of Issue: if auto-redirect despite WCAG but UA blocks, tell user where to go Comment (Including rationale for any proposed change): Pages that refresh so that information is lost may violate WCAG 2.0 guideline 2.2, but refreshing is common anyway. However, a browser may prevent refreshing unless the user chooses to refresh. That's a good solution, but with one caveat: the user may not know why refreshing is supposed to occur, and the user should be well-informed so they can decide what to do next, which may be to do what the redirection was supposed to do. Therefore, the page before refreshing should say why it should refresh. Example: I recently designed a website with a complicated directory structure. Many directories contained only subdirectories. A visitor to one would get a message from my host saying basically that there's nothing to see here. So, I prepared nonroot index.html files that would auto-redirect the visitor to a page. (I since changed my mind, and they no longer auto-refresh.) In the time before auto-redirection, the page would say what would happen, and would provide links, one to do the same thing as auto-redirection and the other to provide an alternative destination (the home page). So, if the browser prevented redirection, the user would know what to do anyway. Proposed Change: If auto-redirection is used despite violating WCAG, since a browser may block auto-redirection, tell the user what the intent was and provide a means of doing it manually. This advice can go into a document that supports WCAG today or a future revision of WCAG.
Received on Sunday, 21 June 2015 23:41:40 UTC