VPAT for MediaWiki

Background
A Voluntary Product Accessibility Template® (VPAT®) is a standard format for information with information about usability of a particular software for people with disabilities. VPATs are the expected form of an Accessibility Conformance Report in the context of U.S. government procurement of software products, and such a report may be required by acquisition or IT staff in government before they buy or install software. The VPAT is a specific table design developed and trademarked by the Information Technology Industry Council (ITI), and the registered trademark sign is appropriate. "VPAT 2.0 users agree not to deviate materially from the template format provided by ITI, and to use the service mark (“®”) where appropriate."

A VPAT contains information regarding how an information and communications technology (ICT) product or service conforms with Section 508, the de facto set of conditions to be discussed in the context of accessibility and U.S. government acquisition. These are not exactly requirements, and are phrased indirectly, because different requirements are appropriate for computer tools and programs of different types, used by different staff, and it's not clear any specific requirement has the force of law exactly.

Relevant disabilities
There is no fixed or complete list of disabilities to be addressed. A central criterion of success is that the software is in fact usable by the people who need to use it, so if people in the relevant organization have a particular need, that's the most important one to address, and it is thinkable to mention that condition in more detail in the VPAT. A common generic list of issues includes: There is a kind of theoretical discussion of impairments or disabilities in which it is important to acknowledge that usability depends on the conditions of users, and furthermore technologies can and do change over time; therefore there is no fixed list, or complete list, or even finite list of the conditions and technologies to address them. This causes huge volumes of discussion amongst advocates, developers, and procurers. In practice it is feasible to be modest in a VPAT, try to acknowledge that perfection is not well-defined and possible in this area, and to address at least some of the conditions above and perhaps more.
 * Some people see red and green as the same; therefore the software should not communicate anything, notably error conditions, SOLELY with a red/green distinction. (Is it 4% of men with this condition? )
 * Some people need or want a dark background on the screen and light-colored lettering. (Details?  Ask D)  Hopefully the software can be configured for this.
 * Fast flashing of bright lights and colors can cause seizures ; the software should not do this, and if so, a VPAT should say that the software does not do this.
 * Some users can't hear, therefore the software should not communicate any information solely by sound, notably error conditions. A VPAT should address this issue.
 * Some users are mobility-impaired, and may not be using a keyboard.  A VPAT should address this.
 * Blind users are likely to be using screen-reader software, usually JAWS, and sometimes a specialized keyboard like this one.

Terminology

 * In the context of a VPAT, the WMF is a 'vendor' of software. A VPAT is often offered by a software vendor, but in this case we'll hack it together open-source style. The authors need to make claims about things the software will EVER do, e.g. use red/green distinctions or make sounds, so either software developers need to be involved or the authors of the VPAT report need to say "as best we know, this can happen and that cannot".
 * Versions: VPAT 1.3 was the standard for a while.  VPAT 2.0 examples start circa Oct 2017, and VPAT 2.1 examples are known by March 2018.  For more, see https://www.itic.org/policy/accessibility/vpat.  The 2.0 format is here: https://www.itic.org/dotAsset/d432b9da-3696-47fe-a521-7d0458d48202.doc.  It's a substantial document, some of which we'll put into wikitext here.  The 2.x formats are designed to cover the categories of software features relevant to Section 508, and WCAG, and the EU standard too.
 * WCAG 2.0 refers to the W3C/WAI Web Content Accessibility Guidelines 2.0. One commenter says the Revised Section 508 mostly adopts WCAG 2.0.
 * Mandate 376/EN 301 549, refers to the European Union’s “Accessibility requirements suitable for public procurement of ICT products and services in Europe”
 * The updated Section 508 is made a rule here but it's talked ABOUT there, without being made clear what's required or functionally what a software person has to do
 * ITI is an organization, whose home web site is here: http://www.itic.org
 * There is a category system built in to a VPAT that we need to define and explain: Web, Electronic Docs, Software, Closed, Authoring Tool.  We need context-specific definitions of these formal terms which appear in most rows.  Closed seems to refer to closed functionality.  Web refers to software that is used through a browser, I guess, and we might therefore say "software" doesn't apply to MediaWiki?  Need to find why these five terms recur all over VPAT 2.0s.
 * Extensions: Note that MediaWiki is usually installed with some of many extensions, that is, software plugged into it on the server side. Our report below will probably address only core MediaWiki, and a more detailed conversation is needed to address a specific installation and configuration.

Draft VPAT Accesibility Conformance Report
MediaWiki Accessibility Conformance Report VPAT® Version 2.0 – October 2017
 * Name of Product/Version: MediaWiki, version xx
 * Product Description: Wiki software
 * Date:
 * Contact information: (someone @ Wikimedia.org?)
 * Notes: MediaWiki is the central software offering Wikipedia which is widely used by persons with disabilities. (Can we point here to a recent review of or commentary on MediaWiki accessibility? Let's persuade as well as checking various boxes below.) This Accessibility Conformance Report covers Section 508 categories and WCAG Level A, but not WCAG Level AA or AAA, or the EU standard as some VPATs do.
 * Evaluation Methods Used:

Applicable Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:

Terms
These are the categories used in the Conformance Level column:
 * Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
 * Supports with Exceptions: Some functionality of the product does not meet the criterion.
 * Does Not Support: The majority of product functionality does not meet the criterion.
 * Not Applicable: The criterion is not relevant to the product.
 * Not Evaluated: The product has not been evaluated against the criterion. This can be used only in WCAG 2.0 Level AAA.