Re: Revisiting whether & when we might write a technique related to SC 1.4.2 and OS per-app volume settings [was Re: Question about SC 1.4.2 - can this be met by relying on Windows (or otherwise the platform or user agent) to do it for you?]

Hi all.

Firstly, in my opinion allowing SC 1.4.4 to automatically meet just 
because there exists a "full zoom" option was a very bad idea. Many low 
vision users (including me) use the "zoom text only" because we don't 
want to be permanently scrolling left and right to read content, which 
is really annoying and in many cases makes the page almost inusable.

Indeed, if we assume that SC 1.4.4 is met because the "full zoom" is 
used, then it is likely that SC 1.4.8 #5 will not be met. I would bet 
that most pages cannot meet both criteria at the same time if we rely on 
  full zoom to meet both.

In any case, I agree with David that we are talking about forcing users 
to find an obscure option that most users (including me) don't even know 
about. And, more importantly, if we allow this kind of things, then we 
can be tempted to also add other "automaticly sufficient" techniques for 
other SCs, for example:

1.4.3/1.4.6 Contrast: Windows platforms allow high contrast settings to 
change the colours of background and text; most browsers (any OS) also 
allow the user to change page colours overriding author's styles. We can 
even assume that, since MacOS allows users to increase contrast with a 
slider, it would be possible to add a technique of "relying on OS 
features that allow users to control colours or contrast of web content"

2.2.2 Pause, Stop, Hide: since we can resize the browser window, maybe 
we can put the offending content on the right side and consider that 
"users are able to resize the browser's window to hide the offending 
content", eliminating the need to provide an explicit option.

2.4.5 Multiple ways: of course, if our website is properly indexed in 
Google or other search engines, we can rely on users trying to find our 
pages using these engines instead of providing the options ourselves. 
Indeed, I know many users that use this technique because sometimes 
Google works better than the internal search function.

3.2.1 On Focus: Most modern browsers have built-in pop-up blockers, so 
we can rely on this feature and create tons of pop-up windows that open 
automatically when the page is loaded.

These are just a few examples, I guess that many other "auto-sufficient" 
techniques could be added with a bit of creativity, since modern 
browsers and operating systems include many features that allow better 
user experience. But relying on this features to provide real 
accessibility is not a good idea if you really pretend to eliminate real 
barriers.

And, most importantly, including these kind of techniques in a WCAG 
document would communicate the idea that accessibility implies that 
disabled users must be experts to obtain an equivalent result to that of 
non-disabled users. They need to be experts to have the same rights.

Regards,
Ramón.

PS: I mentioned PDF because I also think that the "sufficient" PDF 
techniques are not a good idea, at least without explicitly mentioning, 
for each technique, its accessibility support. Now, the only information 
about accessibility support for PDF is in the main document about PDF 
techniques, and it does not explain the reality of their support on 
different operating systems. It just says -more or less- that "PDF can 
be read on MacOS", but this is far from "It can be read in an accessible 
way".


David wrote:

> It doesn’t seem the same to me as the 1.4.4 situation...
>  
> 
> -        1.4.4 require sighted folks to:    hit Control/Cmd + 
>          or CTRL+ Scroll wheel            in any browser, any OS
> 
> -        The proposed technique for 1.4.2 is something like this:
> 
>  
> 
> Press WINKEY+B,
> 
> Hit Arrow until you focus on “speakers”,  
> 
> Hit space bar,
> 
> Tab twice to focus on Mixer,
> 
> Hit spacebar,
> 
> Hit Tab key between 2 and 10 times until focus is on the mute button for 
> Firefox,
> 
> Press spacebar
> 
> Hit escape to close
> 
> Press alt-tab until you get back to your browser
> 
> Surf site
> 
> If you want to play a YouTube Video or hear the news, do this all over 
> again to unmute, and when you want to surf again repeat to mute again. 
> Note: this won’t work in IE.
> 
> A parallel situation for 1.4.4 might be to force the user to change the 
> resolution of their screen or turn on the windows magnifier, not a 
> little browser control. I don’t think we would have consented on 1.4.4 
> language if browsers couldn’t easily do this.
> 
> I don’t want to just create a technique if the is no indication that 
> browsers will create a control, or we will create a little widget to do 
> this. Such as a macro that throws a control in the browser, or an exe 
> that is a macro people can download or something... I’m nervous it will 
> just be an orphan technique with no real help for people with 
> disabilities, which is why we all do this.
> 
> Cheers
> David MacDonald
>  
> 
> *From:* Peter Korn [mailto:peter.korn@oracle.com]
> *Sent:* June-27-13 4:45 PM
> *To:* David MacDonald
> *Cc:* WCAG
> *Subject:* Re: Revisiting whether & when we might write a technique 
> related to SC 1.4.2 and OS per-app volume settings [was Re: Question 
> about SC 1.4.2 - can this be met by relying on Windows (or otherwise the 
> platform or user agent) to do it for you?]
> 
>  
> 
> David,
> 
> Is 1.4.4 invalidated?  No.  It is just met automatically most of the 
> time (by pretty universal user-agent zoom), and responsible authors 
> check to make sure they didn't break it (and it can be broken - e.g. 
> with embedded content rendered by plug-ins, etc.).
> 
> What is being discussed, I think, is the first step toward 1.4.2 being 
> met automatically most of the time, through the possible creation of a 
> success technique that works today - in a more cumbersome way than would 
> be ideal (though arguably no MORE cumbersome than on existing web pages) 
> - on two OS releases.
> 
> 
> Regards,
> 
> Peter
> 
> On 6/27/2013 1:16 PM, David MacDonald wrote:
> 
>     Aren't we just basically invalidating 1.4.2  and letting authors say
>     "it's not my problem my music bugs you, learn your os?  I'm not
>     convinced ...
> 
> 
>     Sent from my iPhone
> 
> 
>     On 2013-06-27, at 2:11 PM, Loretta Guarino Reid
>     <lorettaguarino@google.com <mailto:lorettaguarino@google.com>> wrote:
> 
>     Just a few opinions from me:
> 
>     1. I think there is probably no reason this couldn't be a sufficient
>     technique, with the usual accessibility support caveats
> 
>     2. Publishing it as a WCAG technique only helps in making authors
>     more aware of it. It does not help with the problem of how to reach
>     end users who would be expected to know about this setting.
> 
>     3. Do we really think that documenting this particular technique,
>     which has the issues that have been discussed, is a more important
>     use of our time than all of the other potential work the WG has
>     before us? (That said, we've probably spent more time discussing it
>     than it would take to write it up.)
> 
>     On Thu, Jun 27, 2013 at 10:15 AM, Peter Korn <peter.korn@oracle.com
>     <mailto:peter.korn@oracle.com>> wrote:
> 
>     Colleagues (and especially Gregg),
> 
>     Given the note from Christophe below pointing out that we have a
>     second desktop OS that offers this functionality (Linux with GNOME),
>     and a message earlier today from Ramón Corominas pointing out that
>     we have techniques for PDF accessibility that appear to only work on
>     a single platform (Windows), I find myself wondering if there we
>     aren't being consistent in when WCAG may publish a technique for
>     meeting a success criteria.
> 
>     It seems to me the argument now boils down to "too few users know
>     about this option" (since the argument "this option isn't available
>     in enough places" doesn't seem to have prevented PDF techniques). 
> 
>     If that is the case, then wouldn't publishing a technique - which
>     made clear it required recent versions of Windows and/or GNOME - BE
>     a way of getting more publicity for this?  And wouldn't it BE a way
>     to better bring it to the attention of user agent & platform creators?
> 
>     Regards,
>     Peter

Received on Thursday, 27 June 2013 23:22:44 UTC