RE: Technical baseline clause revisited?

Alan,
conformance with WCAG success criteria does not, as you state, say that 
the web app must support "all of each or all of any".  So, for example if 
the web app requires JavaScript, or WAI ARIA web technology, and they show 
that it can be accessibility supported by AT, OS, etc. and pass the 
success criteria, then they have met their burden of conformance of 
meeting the success criteria.  They could and perhaps should also 
"document what they rely on", in other words, if the user or employee 
doesn't have the AT or OS or browser that also support JavaScript or WAI 
ARIA, then the web app is still conformant (in my opinion), but not 
available or usable without the supporting AT, OS, etc.  Some scenarios 
might include: its accessibility supported on Windows 10 with Edge, 
Firefox, and Chrome (but not Safari), and on iOS and MacOS, but not 
Android, Linux, etc. 


Another example of limits to "accessibility supported" include other 
language versions or perhaps in other countries where there isn't a 
supporting OS, or AT, or browser. In other words, the conformance claim is 
limited in a sense. But, there is an implied "more than one" in the WCAG 
conformance because WCAG uses (on purpose if I remember correctly) the 
plural of technologies, browsers, operating systems, and other user agents 
 

In my opinion It is up to the policy makers to set the minimum supporting 
technologies beyond two.  For example, a policy maker inside a company may 
say that all employee facing apps must be accessibility supported on 
Firefox v 45, Chrome, and IE and JAWS 15, ZoomText, etc. and Windows and 
MacOS with VoiceOver.  A policy maker for a country or state may also do 
the same, but they often don't because what is not supported today may be 
in fact be supported next month with no change in the web app.  WCAG does 
not set policy or regulation, its the other way around.

Having said all that, in the specific case of passing the 2.1.1  Keyboard: 
success criteria, it would pass when at least two operating systems have 
supporting keyboard interfaces for interacting with the functionality of 
the web app, without requiring anything else.  What often happens is the 
misunderstanding that some have or at least grey areas in interpretations 
that because an AT may have enhanced features that let the end user 
navigate by heading or control, for example,  that the OS and browser must 
also have that enhanced feature, or that the web app must also have that 
feature.  WCAG doesn't require the web app to have additional AT like 
enhanced features, but that the functionality in the content be operable 
through the keyboard.  So if the web app lets a user open or close, expand 
or collapse, or move left or right, up or down, then all that 
functionality must be available via the keyboard. It is the browser or AT 
combination (not the web app) that must provide additional end user 
enhanced features like navigate by heading for example. 

So, perhaps there is a misunderstanding in interpreting that 'they have a 
set that they know works through their own testing or validation from a 3
rd party and meets the guidelines with that set". But requiring an AT for 
basic keyboard interface beyond operating system support is not meeting 
the intent of the  success criteria for 2.1.1  Keyboard:   Does that need 
to be made more explicit in the Understanding 2.1.1?  Or perhaps the web 
app owner incorrectly implied in their claim wording that the  AT and 
Browsers supported are needed for each and all success criteria, which 
should not be the case for 2.1.1 Keyboard. 
___________
Regards,
Phill Jenkins, 
Senior Engineer & Business Development Executive
IBM Research - IBM Accessibility
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess
ageandability.com




From:   ALAN SMITH <alands289@gmail.com>
To:     Phill Jenkins/Austin/IBM@IBMUS, Katie Haritos-Shea GMAIL 
<ryladog@gmail.com>
Cc:     "'Karen Lewellen'" <klewellen@shellworld.net>, "w3c-wai-ig@w3.org" 
<w3c-wai-ig@w3.org>
Date:   08/24/2016 08:54 PM
Subject:        RE: Technical baseline clause revisited?



My challenge would be that if a website works with only one set of or a 
couple sets of browser/screen reader combinations does it not meet the 
wording of ?. it [the website] works with assistive technologies (AT) and 
the accessibility features of operating systems, browsers, and other user 
agents." 
This statement does not say all of each or all of any.
 
Am I getting too literal I?m my interpretation of it. 
 
Companies cannot be expected to support every and all combinations of all 
of the items in the statement. 
Therefore, if they have a set that they know works through their own 
testing or validation from a 3rd party and meets the guidelines with that 
set, then why cannot they state which ones they support and use to have 
their website compliant?
 
Alan

Sent from Mail for Windows 10
 
From: Phill Jenkins
Sent: Wednesday, August 24, 2016 8:25 PM
To: Katie Haritos-Shea GMAIL
Cc: 'Karen Lewellen'; w3c-wai-ig@w3.org
Subject: RE: Technical baseline clause revisited?
 
My additional point to add on this thread is that there can be confusion 
in terminology at times, especially across legal terms and applicability. 
For example, in order for the entity to comply with some provision of 
AODA, their web site or web app should conform to the 36 Success Criteria 
of WCAG 2.0 that are referenced in AODA.  e.g. conform to the technical 
standard means the web site passes the success criteria.  A company (or 
entity) complies with the law, a web site conforms to the standard.  The 
company can't say their web site conforms to the standard by requiring a 
certain assistive technology, because, as Katie quoted, the standard 
itself says: ". . . it [the website] works with assistive technologies 
(AT) and the accessibility features of operating systems, browsers, and 
other user agents." 

In other words, the entity complies with AODA by claiming which web 
technologies (e.g. HTML5, CSS, JavaScript, etc.) they are relying upon, 
not which assistive technologies they are relying upon to pass the WCAG 
success criteria. The keyboard success criteria does not imply nor should 
it rely on any assistive technology, it explicitly says through a keyboard 
interface, which is typically part of the operating system platform and a 
physically attached keyboard, period. 

2.1.1Keyboard: All functionalityof 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) 

A Keyboard interface is an operating system feature that is used by the 
browser, used by the AT, and used by other user agents.  The OS feature 
also provides the physical (or Bluetooth connected) keyboard device 
support to the human end user as well.
___________
Regards,
Phill Jenkins, 
Senior Engineer & Business Development Executive
IBM Research - IBM Accessibility
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess
ageandability.com




From:        "Katie Haritos-Shea GMAIL" <ryladog@gmail.com>
To:        "'Karen Lewellen'" <klewellen@shellworld.net>, 
<w3c-wai-ig@w3.org>
Date:        08/24/2016 12:32 PM
Subject:        RE: Technical baseline clause revisited?




Karen,

WCAG 2, as a technical standard, cannot mandate human rights legal 
requirements. 

It is the laws in counties that point to and require the usage of 
particular standards. 

The requirement to 'not mandate specific assistive technologies' for use 
by users with disabilities, would be covered by the human or disability 
rights laws in Ontario. I am sorry I am not familiar enough with the AODA, 
it is possible that such a clause exists. 

It seems clear to me that organizations cannot mandate what you must use. 
But I do not know if that is a provision of your laws. They certainly 
should be clearly identifying what AT they do support in their 
Accessibility Statements. And, they cannot claim conformance to WCAG 2 if 
they do not have some sort of identified accessibility support.

????Here is the definition of Accessibility Supported from the WCAG 2 
standard:

" Accessibility Supported
Using a technology in a way that is accessibility supported means that it 
works with assistive technologies (AT) and the accessibility features of 
operating systems, browsers, and other user agents. Technology features 
can only be relied upon to conform to WCAG 2.0 success criteria if they 
are used in a way that is "accessibility supported". Technology features 
can be used in ways that are not accessibility supported (do not work with 
assistive technologies, etc.) as long as they are not relied upon to 
conform to any success criterion (i.e., the same information or 
functionality is also available another way that is supported). "

Also Conformance Claim number 4 from the WCAG 2 standard says:

" 4. Only Accessibility-Supported Ways of Using Technologies: Only 
accessibility-supported ways of using technologies are relied upon to 
satisfy the success criteria. Any information or functionality that is 
provided in a way that is not accessibility supported is also available in 
a way that is accessibility supported. (See Understanding accessibility 
support.)"

Hopefully someone else who lknows more about AODA will chime in 'not 
mandate specific assistive technologies' for use by users with 
disabilities, if it exists in Ontarian law.


* katie *

Katie Haritos-Shea 
Principal ICT Accessibility Architect
Chair, W3C WAI (Web Accessibility Initiative) Interest Group (@w3c_wai)

JOIN US: Subscribe to the WAI IG list, send an email to 
w3c-wai-ig-request@w3.org with ?subscribe? as the subject line.

Personal: Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn 
Profile | Office: 703-371-5545 | @ryladog

-----Original Message-----
From: Karen Lewellen [mailto:klewellen@shellworld.net] 
Sent: Tuesday, August 23, 2016 11:19 AM
To: w3c-wai-ig@w3.org
Subject: Technical baseline clause revisited?

Good morning everyone,
Before I start let me express my appreciation  to each of you for your 
commitment to inclusion.  At the end of the day the resources alone at 
least for me  fortifies my hope.
I have what I trust is a simple question,  although  the situation is a 
tad complex.
A couple of years back at least we discussed the technical baseline 
clause, how some companies use this to avoid compliance  even with basic 
things like keyboard functioning by stating they use say jaws, You must as 
well.
My understanding then was that a company cannot place such requirements on
 the general public.
Can anyone document for me if this remains the case?
I have one of those situations that if I used what the company is claiming 
I must use...it would actually do me physical harm.
so I want to share with the mediator that making such requirements 
violates WACG in general.  I am in Ontario and was told privately that the 
AODA  incorporates WACG into its standards.  The Ontario Human Rights Code 
has a greater level of mandate  undue hardship,  meaning regardless the 
company is violating the latter, but they are claiming the former.
Thoughts?
Thanks,
Kare