Re: Does WCAG allow AT to be used to meet the SC?

Hi Bruce,

thanks for doing this -- I was going to do it myself just to see what I saw.

However my conclusions from your scan are quite different from yours -- and seems to confirm that the WCAG's decision in crafting the provisions to allow AT to be a solution creates no real problems and in fact may encourage developments that can enhance accessibility.   For those with limited time I copied by conclusions from the bottom up to the top here. 


Of the list of 10 provisions you identified as being made moot because AT could be assumed to meet them. 

3 - are incorrect and cannot be met by AT (2.1.1,  2.1.3,  2.2.2)
2 - you do not need AT to meet   (2.4.7, and 1.4.4)  -- modern browsers cause them to be met automatically already now
3 - are Level AAA  so are never required (1.4.8, 1.4.6, 1.2.6) - so talking about people getting out of them is not an issue.  They are there for people who want to make pages more accessible.  
1 -  (1.2.2  Captions) would require a lot more technology than Google, which only provided subtitles (words only, not speaker id or sounds etc).  Assistive technologies that can provide all the parts defined in WCAG as being necessary for captions is a LOOOONG way off. Way longer than the life of the guidelines or the regulations  (10 years or more - especially for identifying the  full range of important sound effects that are mixed in with music and all sorts of irrelevant sounds).  

That leaves one provision  - Contrast - where AT would cause a provision at level A to be met.   This is provision is probably one of the most troubling to authors and one that a feature could very likely be built directly into browsers in the near future.   When this is done, I would think that the success criterion SHOULD be met by that feature -- It will allow users to control contrast much better, save a lot of time on authors part, and provide even better access on even more pages.  
	 In the meantime one COULD argue that AT can be assumed to meet it.   
	This would depend on the "Accessibility Supported" provision however.    And that reads "that it must be supported by users AT".   Any regulatory body that wanted to close the option off for authors designing pages that would be used by people  who do not have AT, would just have to say that for the purpose of their regulations, "supported by user's AT" means that it is supported by AT that it is reasonable to assume a user has.   It is reasonable to assume the a blind user has a screen reader.  But it may be judged to not be reasonable to assume that every person with a need for sufficient contrast (and no magnification) will have a contrast enhancement tool (unless and until of course it is built into the Browsers -- and is there for everyone - at which time the success criterion SHOULD be met by it.) 



On the flip side,  if you assume that AT cannot be used to meet the SC, then there are many that have no meaning at all including all of the programmatically determined provisions which specifically say they depend on AT.   In addition it is clear from the "accessibility supported" descriptions that AT as a solution to accessibility is intended. 


Take a look and lets talk some more. 


Thanks much

Gregg




The provisions one by one. 


> 
> Proof by demonstration, Part the Second (reductio ad absurdum, with appropriate assistive technology, all the following are satisfied, so they are rendered moot, and can be disregarded):
> 
> 1.2.2 Captions (Prerecorded):  Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.  (Level A)
> 
> This one is a stretch at present since the AT is not there yet, but it is easy to image technology like Google machine-generated automatic captions (but that works for media besides YouTube) being a paid application.

And when it can provide such quality captions including speaker identification, identification of speakers off screen, descriptions of all environmental sounds etc, then indeed this SC will be satisfied.  Lets hope that industry invests in doing this.  Given the low level of material that is captioned and the fact that the CVAA does not require any material not generated for TV be captioned  this would be a major advance. 

> 
>    1.2.6 Sign Language (Prerecorded):  Sign language interpretation is provided for all prerecorded audio content in synchronized media.  (Level AAA) 
> 
> Since an author can assume people who need it have AT like Signing Avatar from VCom3D, this SC can be assumed to be satisfied.

This would require that speech to text was available , and then text to sign and then sign to avatar.   And when this is available this (level AAA) SC would be met.  
Level AAA is never required.  So it is only there to say what is good. If people want to get out of this they can just not do it.  They don't have to rely on an AT approach.  


> 
> 1.4.3 Contrast (Minimum):  The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:…  (Level AA)
> 
> Since an author can assume people who need it have AT like ZoomText or MAGic, this SC can be assumed to be satisfied.



> 
> 1.4.4 Resize text:  Except for captions and images of text, text can be resized up to 200 percent without loss of content or functionality.  (Level AA) 
> 
> Since an author can assume people who need it have AT like ZoomText or MAGic, this SC can be assumed to be satisfied.

This is already met by the zoom feature in browsers -- so no need for AT.   



> 
>    1.4.6 Contrast (Enhanced):  The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:  (Level AAA)
> 
> Since an author can assume people who need it have AT like ZoomText or MAGic, this SC can be assumed to be satisfied.

Level AAA is never required.  So it is only there to say what is good. If people want to get out of this they can just not do it.  They don't have to rely on an AT approach.  


> 
>    1.4.8 Visual Presentation:  For the visual presentation of blocks of text, a mechanism is available to achieve the following:…  (Level AAA) 
> 
> Since AT productsT like ZoomText or MAGic provide such features for most content, this SC can be assumed to be satisfied by authors.

Level AAA is never required.  So it is only there to say what is good. If people want to get out of this they can just not do it.  They don't have to rely on an AT approach.  


> 
>   2.1.1 Keyboard:  All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.  (Level A)
> 
> Since there are numerous AT products that emulate mouse functions through the keyboard or even switches, this SC can be assumed by authors to be sufficiently addressed.

Read the provision carefully.   Mouse emulation is specifically disallowed as a way to meet this success criterion.


> 
>   2.1.3 Keyboard (No Exception):  All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.  (Level AAA)
> 
> Since there are numerous AT products that emulate mouse functions through the keyboard or even switches, this SC can be assumed by authors to be sufficiently addressed.

Ditto.  Cannot use a mouse emulator for this.


> 
>   2.2.2 Pause, Stop, Hide:  For moving, blinking, scrolling, or auto-updating information, all of the following are true:…  (Level A)
> 
> Since there are numerous products for slowing down computers (both for old games and as AT), this SC can be assumed to be addressed by authors.

Slowing down a computer will not satisfy this provision.   


> 
>   2.4.7 Focus Visible:  Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.  (Level AA)
> 
> Since AT products like ZoomText and MAGic provide enhanced cursors, this SC can be assumed to be satisfied by authors.

This is one that is essentially advisory.   you do not need AT for this.   Keyboard indicators are ALWAYS visible.  Else they would not be indicators.   SO this one is met by default.  It used to say 'highly' visible but could not survive testability provisions.  We were going to remove it but decided to keep it in and use as an anchor for all sorts of best practice around this provision. 






Conclusion: 

So of the list of 10 provisions 

3 - are incorrect and cannot be met by AT (2.1.1,  2.1.3,  2.2.2)
2 - you do not need AT to meet   (2.4.7, and 1.4.4)  -- modern browsers cause them to be met automatically
3 - are Level AAA  so are never required (1.4.8, 1.4.6, 1.2.6) - so talking about people getting out of them is not an issue.  They are there for people who want to make pages more accessible.  
1 -  (1.2.2  Captions) would require a lot more technology than Google, which only provided subtitles (words only, not speaker id or sounds etc), and is a long way off. Way longer than the life of the guidelines or the regulations  (10 years or more - especially for identifying important sound effects).  


That leaves one provision  - Contrast - where AT would cause the provision at level A (or AA) to be met.   This is probably one of the most troubling to authors and one that a feature could very likely be built directly into browsers in the near future.   When this is done it SHOULD be met by that -- and it will allow users to control contrast much better, save a lot of time on authors parts and provide even better access on even more pages.   In the meantime one could argue that AT can meet it.   This would depend on the "Accessibility Supported" provision however.    And that reads "that it must be supported by users AT".   Any regulatory body that wanted to close option off for those who do not have AT would just have to say that for the purpose of their regulations, "supported by user's AT" means that it is supported by AT that it is reasonable to assume a user has.   It is reasonable to assume the a blind user has a screen reader.  But it may be judged to not be reasonable to assume that every person with a need for sufficient contrast (and no magnification) will have a contrast enhancement tool (unless of course it is built into the Browsers -- so is there for everyone.) 



On the flip side,  if you assume that AT cannot be used to meet the SC, then there are many that have no meaning at all including all of the programmatically determined provisions which specifically say they depend on AT.   In addition it is clear from the "accessibility supported" descriptions that AT as a solution to accessibility is intended.