Marketplace Accessibility Test

Overview

The inaccessible page provided in the zip file will enable you to run your tests.

Instructions

1. Review the associated web page("/inaccessible-page-2/index.html") for accessibility as defined by WCAG 2.1 at Level AA.
2. Form submit buttons do not submit anything, and so the forms cannot readily be assessed against WCAG 2.1 SC 3.3.1 Error Identification and 3.3.3 Error Suggestion, even if some browsers implement their own error validation and messaging.
3. Identify every WCAG 2.1 faliure that you can, noting the following information for each failure:
   • the specific WCAG 2.1 Success Criterion (SC) that is failed
   • its location in the web page
   • a brief description of how that SC is failed.
4. Please use a spreadsheet, e.g. MS Excel, to record your test results, with columns at least for the WCAG 2.1 SC failed, the failure's location in the page, and a brief explanation of the failure. Other columns can be used and data recorded at your discretion.
5. Some accessibility issues represent failures of multiple WCAG 2.1 SC. Be Sure to identify every WCAG 2.1 SC that is failed in each case.  For instance, where a user interface component contains nothing but an image lacking a text alternative, and otherwise has no mechanism for deriving an accessible name, there are failures of SC 1.1.1 Non-text Content (image lacks text alternative) and SC 4.1.2 Name, Role, Value (UI component lacks programmatically determinable name).
6. Avoid false positives as these are considered assessment errors and will negatively impact your test score.
7. Feel free to note best practices or accessibility issues that are not WCAG 2.1 failures.  However, in doing so, be careful to avoid notign these as failures of WCAG if they are not, as these will be considered false positives.
8. Describing the impact of a WCAG failure is not the same as describing the failure itself.  For example, where a 2nd level heading is marked up as a 3rd level heading, there is a failure of SC 1.3.1.  While impact of the failure might be described in different ways, e.g. "Screen reader users will think that the heading is a subheading to the previous section", the failure itself has to do with the text being visually presented as and logically acting as a 2nd level heading (h2), but programmatically being identified as a 3rd level heading (h3) A description of the failure is what is requried for the test, not a description of the impact.
9. It is not required to identify fixes or solutions for any of the WCAG 2.1 failures that you identify.
10. Note that the test page is a local file that is not served from a web server as part of an actual website.  Accordingly:
    1. Links in the page do not work (href="#"), but you should act as if they would take the user to a relevant URL if activated.
    2. Form submit buttons do not submit anything, and so the forms cannot readily be assessed against WCAG 2.1 SC 3.3.1 Error Identification and 3.3.3 Error Suggestion, even if some browsers implement their own error validation and messaging.
    3. As the page is not part of a website or set of web pages, it cannot be assessed against WCAG 2.1 SC 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification.
    4. As the page is a local file, some assessment tools cannot be used.  However, it is simple to set up a test environment from which the file can be served over HTTP, and assessors are encouraged to do so where the tools they use require it.
    5. if testing the page as a local file in Internet Explorere, you might need to uncheck the "Display intranet sites in Compatibility View" setting in the "Compatibility View Settings" dialog in order to have the page rendered in standards mode.
11. Once you have completed your assessment of the associated web page, deliver your response to marketplace@dia.govt.nz.

Downloads

Zip folder containing the inaccessible test page and supporting artefacts [ZIP, 6.5 MB] [6.53MB]