UC Berkeley Confluence Accessibility Review

UC Berkeley Confluence – Accessibility Review Review Date: 12/19/13 Application version: 5.2.5

In order to comply with the UC Accessibility Policy, the Web Accessibility Team has reviewed a confluence instance. This review included using a screen reader on the page to locate specific projects, read project wikis, locate specific documents, and explore wiki pages in-depth. Accessibility considerations during this review  Screen reader accessibility  Low vision  Keyboard-only user Tools used  JAWS for Windows, version 15  Firefox 26  Windows 7  Color contrast analyzer Findings Cross-application findings:  Whenever content is dynamically changed by user action on any page, the screen reader user is not informed that a change has occurred and may not ever discover the updated content. o Examples: . Clicking "Add to Favorites", there was no indication via screen reader that the page had actually been added. . Link to Child Pages at the bottom of the page: the child pages are not expanded by default, the user has to click first, and there's no indication to screen reader that the list of child pages has been expanded. o Recommendation: ARIA alert to indicate to listener that the content has been dynamically changed.

When using project search:  Search results page was difficult to navigate: o Tabbing order did not follow visual appearance. o Heading order not correct (skipped from heading 1 to heading 3). o Left-side menu: “By” and “Space” items are the only ones that the screen reader could tab to (rest of the filters not available). o When screen reader was able to click on a filter in the left-side menu, the filter updates for the visual user, but does not indicate via screen reader that the search content has dynamically updated. o The icons next to search items are set as background images to differentiate types to the sighted viewer, but screen reader can't tell the different types of items (attachments vs. pages, etc.). Icons could be added as images with alt text.

When exploring individual wiki pages:  There is no "main content" region, which should be added to indicate where the primary content is to the screen reader. The heading 2 on page (see screenshot) should be where the main content region begins.  It might be helpful to change the footer region to a section as opposed to nesting within the div.  The title of the page is self-linked, which will bring the user back to the same page once clicked (application-wide issue).  In the sidebar: o The icons next to the sidebar items need better alt text o There needs to be notification to the screen reader user that the sub-menu has been activated (or ARIA roles for expand/collapse, or other accessible expand/collapse options). o The icons are not very distinguishable in general (for those with low vision); the color contrast fails for the icons, and the color of the text barely passes.  When adding a comment to the page, screen reader was unable to review back the text that had been typed. Overall, text editor is inherently broken for screen reader.  Link to Child Pages at the bottom of the page: the child pages are not expanded by default, the user has to click first, and there's no indication to screen reader that the list of child pages has been expanded. Recommendations  Text editor: since text editor is inherently broken and unusable by a screen reader user, the text editor should be completely overhauled and/or replaced with an accessible alternative.  For dynamic content: ARIA (Accessible-Rich Internet Applications) alert to indicate to user that the content has been dynamically changed.  For semantic structure (headings): all pages should be reviewed to ensure that no heading levels have been skipped. Specifically, on search results page, search results should be h2 instead of h3.  All images should have appropriate alt tags.  Developer should use ARIA landmarks to help screen reader users identify main content and navigation regions on pages.