This document:Public document·View comments·Disposition of Comments·
Nearby:Accessibility Guidelines Working Group Other specs in this tool Accessibility Guidelines Working Group's Issue tracker
Quick access to LC-2582 LC-2583 LC-2584 LC-2595 LC-2596 LC-2601 LC-2605 LC-2610 LC-2611 LC-2612 LC-2613 LC-2619 LC-2620 LC-2622 LC-2625 LC-2626 LC-2627 LC-2628 LC-2631 LC-2632 LC-2646 LC-2647 LC-2648 LC-2683 LC-2684 LC-2703 LC-2704 LC-2718 LC-2719 LC-2723 LC-2724 LC-2726 LC-2728 LC-2729 LC-2730 LC-2745 LC-2770 LC-2771 LC-2773
Previous: LC-2619 Next: LC-2729
The Failure test just looks for meta http-equiv with value "refresh" and content > 0. I can see a scenario where the value of content is high (say, 1200 = 20 minutes) and a control is available to extend or turn off auto-refresh (e.g., via DOM scripting of the meta http-eqiv content attribute). In that case, it seems to me that SC 2.2.1 would be met. Would F41 not need to be updated to reflect that option, also in the test procedure? Proposed Change: Not sure - if my argument holds, the test would need to check whether a page actually get refreshed (either by inspecting the content value or, if it is done server-side, by waiting (how long a wait is sensible I am not sure, 20 mins?), and, if the page is found to refresh, look out for a control to extend or turn off the time limit. If a refresh takes place and there is a working control giving users enough time to locate it, the Failure would not apply.