This section covers content that does not meet accessibility regulations on the editor interface for professional web pages (PWPs) - www.imperial.ac.uk/personalise/, which enables Imperial staff to edit and publish their PWP profiles.
Last updated: 28 August 2020
- The label entitled 'Username' contains an incorrect 'for' attribute, referring to a field which doesn't exist.
- The file upload input (input#fileToUpload) is missing an associated label to identify its purpose
- The modal dialog to upload a CV contains an input field (input#uploadfile) without an associated label.
- The button to refresh symplectic data (input#refreshSymplectic) does not have an aria label or value, so cannot be identified programmatically.
- When editing the research area heading, an input is created when the heading is clicked (input#heading-input-1), there is no associated label with this.
- When editing the navigation title and page title an unlabelled input is created.
- When modifying the content heading the input which is added to the DOM does not have an associated label.
Info and relationships
- A container (div#main) is provided, however this has no semantic role
- The login page has no h1 tag on the page, heading level starts at h2
- The footer element contains a list of links (footer a) which are output as part of a paragraph rather than an unordered list.
- The help section, when activated contains a list of links. These are marked up as anonymous divs instead of an unordered list of links.
- On the editors screen, rhe main content of this page is a multi-select box containing hundreds of entries, visually organised into a tree structure. For assistive technologies this is just a very long, non-hierarchical single group of options and would be very difficult to quickly navigate.
- When an item is selected, a section containing an unordered list of users is created. The section is labelled, however the label refers to the unordered list which is invalid use of html.
When the help 'presentation' is triggered, boxes are added visually near the elements they are referring to. However these are added after the main body content, rather than as a sibling of the element they relate to. This means an assistive technology would have no idea to what element they were providing help for.
The help icon throughout the editor has no textual description to indicate that it exists or is clickable, it is purely reliant on visual identification.
Identify input purpose
Autocomplete attributes are missing from the login form, these aid some assistive technologies to automatically input the correct details without requiring user input.
Use of colour
The following elements do not have sufficient colour contrast between the background and the text:
- Several reused components do not contain sufficient contrast to meet the guidelines, specifically headings (h2), navigation (header nav a) and success buttons.
- The user identifier (span.quiet) in the editors list does not meet contrast requirements
- Icons used to show the editable areas do not meet contrast requirements of 3:1
- Icons used in the Data Sources area do not meet contrast requirements.
The following issues occur when the browser window is zoomed to 200%:
- The white footer text expands beyond its darker container and ends up on a light background making it unreadable.
- The PWP editor was not built to be used on a mobile or heavily zoomed viewport, and thus critical functionality such as the ability to edit or publish content is hidden by styling and unusable.
When the changes to the text formatting are made,
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
The following aspects do not meet the guidelines:
- The username label is obstructed by the input area when text is spaced according to the guideline requirement.
- The modal dialog to upload an image (#changePortraitModal .modal) has overflowing text on the main two buttons when the text is spaced according to the guideline requirement.
- When text is spaced according to the guideline requirement, the add buttons become visually disassociated with the user to which they are related.
- It is not possible to focus the editable areas (.editable) to modify display name or content with only keyboard navigation.
- It is possible to trigger the modal to replace the portrait image, however it malfunctions causing the crop tool to be loaded immediately, obstructed by the other modal.
- It is not possible to focus the help icon (div#getHelp) using only keyboard navigation.
- It is not possible to focus the yes/no switches (div.sliderButton) using keyboard only navigation.
- It is not possible to focus the editable areas (.editable) to modify display name or content with only keyboard navigation.
- It is not possible to focus the remove icon button (input#deleteContentArea1) using only keyboard navigation.
- It is not possible to focus the navigation title (span#resource-name) or page title (span#resource-title) controls using only keyboard navigation.
- It is not possible to choose a department to trigger the user listing using keyboard only navigation.
Bypass blocks or 'skip-to' links are not implemented on the page template.
The data sources section (#dataSources) has the link for each source as the very first child, before the title. This means the link is out of context and focuses in an illogical order when using keyboard navigation different from the visual order.
The purpose of each of the following links cannot be determined from the link text alone or from the link text together with its programmatically determined link context:
The two links in the DSS section of the Data sources area (div#dataSources) are the raw urls rather than a descriptive link, this means assistive technologies will read out each letter of the url instead of telling the user what they specifically link to.
Multiple ways (to locate a page)
There must be more than one way to locate a page within a set of pages except where the Web Page is the result of, or a step in, a process.
Only the top navigation is provided to be able to navigate the pages.
- Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
- There is an empty <a> tag in the element for uploading a CV if no CV has previously been uploaded, this can be focused with the keyboard but has no highlight or content.
The control to modify the portrait image is focusable but there is no highlight for this
Language of the page
The language is not defined as part of the template.
Error identification and suggestion
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. The following do not meet this requirement:
- Both username and password fields are not required on teh login screen, however if one is missing then the form submits and the page reloads with a non-descriptive message. Users may mistake this message to mean that the actual login form is not working, as opposed to one of the fields was missing. The message is displayed after the fields, which also could cause confusion for screen-readers who will read out all of the content before getting to the message.
- If the display name (#bannername input) is cleared, the only indication that it is a required field is that the input is outlined with red, no text description is given.
- If the Display Twitter timeline switch is enabled then the Twitter is not mandatory. This means that a user can enable the twitter timeline and leave the page without it being properly configured, causing it to become disabled again.
- If the research section heading (input#heading-input-1) is empty, the field is outlined in red but there is no text description to re-enforce this.
- If the page title is empty, then the input is outlined red but no text description is provided to explain this.
Labels or instructions
- On the login screen both fields are required, however this is not enforced in the markup or suggested in the labelling.
- The twitter username input (input#twitter-username) does not accept the common format for twitter usernames, i.e. prefixed with an @. The error message doesn't explain this clearly.
- When adding a new content area to the research screen, using the button (input#addContentArea) a new, empty content area is created with no indication of what needs to be done next to complete it.
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
- In the head of the template a meta tag is used to show compatibility with versions of Internet Explorer (https://docs.microsoft.com/en-us/openspecs/ie_standards/ms-iedoco/380e2488-f5eb-4457-a07a-0cb1b6e4b4b5), this has been defined incorrectly and is also obsolete.
- On the login page, the username label is not associated correctly with the username input.
- The hidden input for the display name field is missing a name attribute to identify it.
- Several buttons (input[type=button].buttonContainer) have empty ids.
- A couple of buttons have empty value attributes, a button input should contain a value to identify itself.
- There are numerous errors related to nesting the rich text content in an inline <span> element.
- The labels for the people (section#choose_people label) and editor (section#choose_editor label) fields reference the unordered lists for people and editors respectively. This is invalid since labels should only reference user input controls in their for attribute.
Name, role and value
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
- When clicking to modify the portrait image, a modal dialog is displayed (div#changePortraitModal). This should contain the appropriate aria role.
- When clicking to modify the display name, an unlabelled input appears.
- When clicking to modify the body content, a modal dialog is shown with the tinymce rich text editor (div#trulyflexibleeditor_container). This should contain the appropriate aria role.
- When clicking to upload a new CV, a modal appears (div#uploadCVModal). This should contain the appropriate aria role and state indicator.
- The button to refresh Symplectic data has no discernible label.
- When clicking to modify the research section title, an unlabelled input appears. The input should contain a label or title to identify itself.
- When clicking to modify research section content, a modal dialog is shown with the tinymce rich text editor (div#trulyflexibleeditor_container). This should contain the appropriate aria role and state indicator.
- When a new content area is added, the previously displayed content area collapses into just the title. This should contain the appropriate aria role.
- When clicking to modify the navigation title, page title or content heading, an unlabelled input appears. The input should contain a label or title.
- When clicking to modify extra page body content, a modal dialog is shown with the tinymce rich text editor (div#trulyflexibleeditor_container). This should contain the appropriate aria role or status indicator.
- When publishing the page, the button changes text several times to indicate different stages of the process. This should be communicated to assistive devices using the aria role=status attribute.
- The error message displayed when an invalid twitter username has been added (div#twitterContainer p.errorMessage) should contain the aria role=alert attribute to allow assistive technologies to parse it correctly.
- The error message displayed when there is a file error when trying to upload a CV (div#uploadCVModal .error p) should contain the aria role=alert attribute to allow assistive technologies to parse it correctly.
- When pressing the button to refresh symplectic (input#refreshSymplectic) the button indicates activity by rotating, this is invisible to assistive technologies and should be accompanied by text to indicate this process is taking place. The text should have aria role=status.