As a user, I would like to have a fully accessible experience.

[binwang89]

Please implement section 508 standards requirements below. App currently not compliant with section 508. Filtered out 2 standards groups that not apply to 14c application (Video-only and Animation) and Flashing. Attached the spreadsheet shows all the minimum section 508 requirements check points that needs to implemented in application system. 508_ToDo (1).xlsx

Tasks:

• [ ] Implement Angular App controls by ARIA related attributes into 14c. (see comments below from Madhu).
• [ ] Tested 14c application for Section 508 compliance by using DHS Trusted Tester Process.
• [ ] Conduct the section 508 remediation for issues in the testing result report.

Acceptance Criteria: The application accessibility testing result must be Section 508 compliance. all issues on trusted tester report must be fixed and compliance. The sample testing result report attached Test_Results_Report-blank.xlsx

[mmurthydol]

Angular App controls must be developed using ARIA related attributes specific to the Angular version (AngularJS = Angular 1.x seems to use ngAria, Angular 2 has aria-).

Current implementation doesn't seem to have any ARIA related attributes in code (except literally in 2 places).

Please look at closed story #163 for potentially helpful development notes. The requirements in this story supercede any comments in#163. #163 will be closed.

[mgwalker]

From #163, I still don't like the story name as I commented here. The QASP also specifies WCAG 2.0 AA, which will necessarily satisfy Section 508.

I would continue to press that this story should be modified to reflect the user interest, not the DOL IT policy interest. The user interest is an app with a fully accessible experience; the user generally will not care about whether that's done by "508 compliance" or WCAG 2.0. That's where the QASP steps in to specify.

Once the story is modified, any special DOL requirements can be placed as comments to the story. Do DOL's requirements deviate from the 508 standard? If not, then the WCAG 2.0 requirement in the QASP should suffice.

[mmurthydol]

The content of two stories can be merged. No problem with that. DOL requirements will override should there be a conflict / else we can't go to production. Perhaps there is no conflict but some one would need to verify...

---

On: 24 July 2017 19:48, "Greg Walker" notifications@github.com wrote:

From #163https://github.com/18F/dol-whd-14c/issues/163, I still don't like the story name as I commented herehttps://github.com/18F/dol-whd-14c/issues/163#issuecomment-311970749. The QASP also specifies WCAG 2.0 AAhttps://github.com/18F/bpa-DOL-WHD-14-c/blob/master/solicitation_documents/QASP.md#40-performance-requirements-summary, which will necessarily satisfy Section 508.

I would continue to press that this story should be modified to reflect the user interest, not the DOL IT policy interest. The user interest is an app with a fully accessible experience; the user generally will not care about whether that's done by "508 compliance" or WCAG 2.0. That's where the QASP steps in to specify.

Once the story is modified, any special DOL requirements can be placed as comments to the story. Do DOL's requirements deviate from the 508 standard? If not, then the WCAG 2.0 requirement in the QASP should suffice.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/18F/dol-whd-14c/issues/198#issuecomment-317613139, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYBER-IO9biZeHDTCV0jrVcESpIFdrkUks5sRVdsgaJpZM4OfpYH.

[binwang89]

After I have reviewed Greg's comments, I decided to change this user story title. the accessible experience is not only for disability, so I did not use disability. we can put WCAG 2.0AA as standard there, but we need to put DHS trusted tester for the manual testing process as acceptance criteria for this user story.

[binwang89]

I updated the https://github.com/18F/dol-whd-14c/issues/89 ( bug for IE). we need to fix the bug for IE asap. DOL is using the DHS trusted tester process for Section 508 testing and the testing tools of Trusted Tester process is designed for IE only.

[mmurthydol]

@binwang89 Please note fix/workaround for #89

[binwang89]

Accessibility acceptance criteria:

1. Keyboard Accessibility [ ] 1.1 An interactive element or function can be accessed or activated by keyboard [ ] 1.2 keyboard "trap" not found [ ] 1.3 if non-standard keyboard commands are needed and they are documented [ ] 1.4 TITLE provides information and equivalent information is found through text or visual context [ ] 1.5 The visual focus can be determined at all times. [ ] 1.6 focus always appears on the element it is programmatically on. [ ] 1.7 if focus remains in the modal dialog box until the box is closed. [ ] 1.8 if focus moves to revealed content OR a description of the content change is provided. [ ] 1.9 the tab order is logical 2. Web: Forms- Web forms include controls (checkboxes, radio buttons etc.), and editable content (text input, select options etc.). [ ] 2.1 All form fields and their instructions and cues have HTML (‘Label for’ and ‘ID’ are used or TITLE is descriptive) or ARIA for association. [ ] 2.2.All 'Label for' and 'ID' are valid code pairs. [ ] 2.3 All form instructions that are provided by mouse over are available onscreen. [ ] 2.4 All ARIA form fields have a NAME property that contains all of the instructions. [ ] 2.5 All ARIA form fields have correct Role, State, and Value properties. [ ] 2.6 All form controls identify their purpose. (Check if there are multiple form controls with the same visual label). 3. Web: Links and User Controls Links and/or user controls must have meaningful names that describe the unique destination, function, and/or purpose of the control for assistive technology. [ ] 3.1 All links have a unique and meaningful description. [ ] 3.2 All scripted elements have a unique and meaningful description. 4. Web: Images Web images include interactive images (links, buttons etc.), static images, charts, diagrams, text rendered as an image, etc. [ ] 4.1 All images have an ALT, TITLE, or ARIA attribute. [ ] 4.2 All meaningful images with ALT have an equivalent text description. [ ] 4.3 All decorative images with ALT have ALT="". [ ] 4.4 All images that contain text with ALT have the same text in the ALT attribute. [ ] 4.5 CAPTCHA images describe their purpose. (DNA, after the captcha is removed) [ ] 4.6 All components that have multiple statuses provide their current status 5. Web: Image Maps (if no image map, then DNA) An image map is a single image that has designated regions or "hotspots" that contain links.Server-side image maps may not be used. Client-side image-maps must be used instead [ ] 5.1 All image maps are client side 6. Color and Contrast Color dependence is using color as the sole means to convey information. There must be contrasting colors/shades at a ratio of 4.5:1 for discerning between background and foreground content. [ ] 6.1 if color is used but is not the only method to provide information. [ ] 6.2 if the contrast ratio is 4.5:1 or greater when comparing all background and foreground colors. Page titles Programmatically identify Page Titles. [ ] 6.3 There is a meaningful page title in plain language. 7. Time Outs Messages and/or instructions to the user requesting their response within a given time are typically associated with sites that require a secure login. This includes both server time outs and client side security time outs. If a time out is about to occur, an alert must be posted for at least 20 seconds and the user must have the option to request more time. The alert (often a pop up window) and option to request more time must be keyboard accessible. [ ] 7.1 The application provides notification before timing out. [ ] 7.2 The application's time out notification is displayed for at least 20 seconds before timing out. [ ] 7.3 The application provides user an option to request more time before timing out. 8. Web: Language A default language must be programmatically identified for each page and for passages that use a language other than the default. [ ] 8.1 if the correct default language for the page is programmatically set. [ ] 8.2 if there is not a passage in a language that differs from the default language of the page.

9 Web: Section Headings Headings must be programmatically identified and must match the visual outline level. [ ] 9.1 All visually apparent headings are programmatically identified with an . ( levels do not need to be correct.) [ ] 9.2 Programmatic levels on all visually apparent headings match the visual structure. 10. Web: Data Tables (If no table, then DNA) Data tables are those tables where the information in a cell requires a row or column header to adequately describe the cell's contents. [ ] 10.1 HTML data tables' row and/or column headers are correctly identified programmatically. [ ] 10.2 if there are data tables but none of them are images. [ ] 10.3 if all HTML complex data tables' data cells are associated with their headers programmatically. [ ] 10.4 if there are complex data tables but none of them are images 11. Web: Style sheet Dependence style sheets are a means to provide visual formatting information to complement a web page's content. [ ] 11.1 The order of the content did not change OR if the order of the content changed but is still logical. [ ] 11.2 All relevant content and information from all meaningful images is available. [ ] 11.3 All content does not overlap and stays legible. [ ] 11.4 If no confusing elements are revealed on the page. 12. Web: Frames Frames are a means of separating out sections of a web page into different navigable regions [ ] 12.1 if all frames' Title or Name is descriptive. 13. Web: Repetitive Content and Links - A method must be provided to skip blocks of repeated content or links on Web pages allowing a user to move directly to page-specific content. [ ] 13.1 There is a method to skip repetitive content. [ ] 13.2 There is a target for all skip links. [ ] 13.3 All skip functions work properly [ ] 13.4 If the relative order of the repeated components is the same as other pages.
14. Web: Required Plug-ins (if no plug-In, then DNA) [ ] 14.1 if on a public site, links to download all required plug-ins are provided. [ ] 14.2 All plug-ins required to view content are compliant. **15. Page Titles
[ ] 15.1 There is meaningful page title in plain language.

[mgwalker]

Whoa, thanks @binwang89! This is fantastic!

I'm wondering if we should add this to the story template as acceptance criteria, and then we can remove the ones that aren't applicable to that particular story. What do you think @simplyshang @ltsheu? Is that too heavy?

[mmurthydol]

As discussed before issue has required to go live tag. We can link and/or refer to this issue in all the UI stories. Story Points are zero by definition for requirements anyways.

[simplyshang]

I think there's value in adding it to the template for each user story, and then removing when we don't need it. There are parts of the Accessibility AC that won't be applicable to each feature, i.e. plug-ins, tables, etc. and we can use the individual story to emphasize which ones apply and need to be met versus which ones are "DNA". I think this will help in making sure we don't overlook anything.

[mmurthydol]

That sounds great @simplyshang @mgwalker ; would still link the accessibility requirements story though.

[binwang89]

@simplyshang agree, some of the items do not apply if we don't use it in our 14c UI. But I still keep them in the list just make sure we don't overlook anything.

[mgwalker]

I have created PR #240 to add the accessibility requirements to the story template along with a link back to this story.

[mmurthydol]

@mgwalker cool Greg. Thanks!

[binwang89]

@simplyshang @ltsheu i think there will be more acceptance criteria from WCAG2AA Standards. what i have listed above are the acceptance criteria from manual test from DHS trusted tester method. Feel free if you want to add more accessibility acceptance criteria. Thanks

[ltsheu]

@binwang89 @mmurthydol @simplyshang I have created a spreadsheet to track the accessibility acceptance criteria. I mainly created it to keep track of things for myself, but then realized maybe it's something we could share. Please give me your feedback on the spreadsheet. If acceptable, perhaps we can add it to the repository.

DOL14c-a11y-acceptance-criteria-status.xlsx

[binwang89]

@ltsheu just review the spreadsheet that you put together to track the accessibility acceptance criteria, it looks good. !!

only one thing - if you compare with the blank excel file that i have uploaded into #198, in that blank, excel report file, it separates each html page into one tab page, there is reason beyond it. if we have more issues found on each html page, you need some space to list all the elements in the slot.

I like the status you created for the excel file - N/A = Not Applicable X = Issues Found IP = Remediation In Progress A = Issues Addressed in Code PASS = Passed testing by DHS Trusted Tester Process.

[ltsheu]

@binwang89 Maybe we could add the status codes to the blank excel file, and we could use that moving forward. It could be placed with the pa11y scans in the repository. I would suggest the following changes to the blank excel file:

• [ ] Add the status code key (N/A = Not Applicable X = Issues Found IP = Remediation In Progress A = Issues Addressed in Code PASS = Passed testing by DHS Trusted Tester Process.) The status codes could be documented in the Test Results column
• [ ] Change the name of the document to something more descriptive such as "DOL14c-a11y-acceptance-criteria.xlsx" as we would be using it during the remediation phase as well as testing phase. The file name is up for discussion!
• [ ] We may need a way to flag items that need more discussion.
• [ ] Add the spreadsheet to the Git repository. I recommend we have a new directory called docs/a11y which would contain the spreadsheet and the pa11y scans.

[binwang89]

@ltsheu that sounds great. let'e document those status codes. Yes, we can name the document anything we like to make it more meaningful for us. to add flag that need more discussion, how do we make it easier ? Make a new directory docs/a11y is good idea to collect all accessibility scan result in one place.

[ltsheu]

@binwang89 Here is the modified spreadsheet document. Please review and let me know if it is okay to use, or please suggest any changes.

• I added a code "D" for flagging things that need discussion.
• Because the Test Results column data entry is locked to "Not Compliant", "Compliant", or "Does Not Apply", I have added a Remediation Status column to track progress with the codes. Perhaps the Test Results column would be used in the Testing phase?

DOL14c-Accessibility-Remediation.xlsx