Related ticket: https://core.trac.wordpress.org/ticket/30486
Result: Taborder footer is fixed, see also the summary at the bottom of this post.
Further: A lot of other issues where found using the table with a screen reader/keyboard.
We asked the testers to log into the test server with a network install and check the label-input relation on pages like:
- All sites
- Add new site
- Edit site ( tabs info, users, themes & settings)
- Add new user
- Check the HTML and check if the input fields still work.
- Anna Natorilla (Desktop Windows 7, IE 11, and JAWS 16)
- Jeff de Wit (Keyboard,ChromeVox and code review)
- Malgorzata Mlynarczyk (NVDA/Firefox + code review)
- Michelle DeYoung (code review and Windows 8.1 using FF/IE/Chrome)
Labels are fixed on Dashboard, All sites, Add new site, Edit site ( tabs info, themes & settings), Add new user, and Settings. Only Edit site on users tab have one checkbox which is not labeled properly. Under Edit Site: User tab, the checkbox before the username does not have a valid label. The label’s for attribute value does not match the id attribute value of the checkbox.
New: The form control primary site does not have a valid label. Location:/wp-admin/my-sites.php
New: Under Post’s quick edit scenario, form controls – date month, day, year, hour, minute, and second does not have a valid label. Each form control does not have an id attribute to match the value of the for attribute with its related label tag. Location: /wp-admin/edit.php
My sites page:
“Primary site” element had no label, but the visible text was read out by the screen reader, as it was marked-up as a header cell (and so was associated with the cell containing the form field).
Add site page
the radio buttons in the “Privacy” section should be wrapped in a <fieldset> element and have a <legend> explaining the purpose of those controls. Otherwise screen reader users only hear “Privacy, yes radio button”, “no radio button” which doesn’t fully explain the purpose of those buttons. Example:
<legend>Privacy: <span>Allow search engines to index this site.</span></legend>
<label class="checkbox" for="blog_public_on">
<input id="blog_public_on" type="radio" checked="checked" value="1" name="blog_public" ffpdm="qh8fxqe6ln9x8748wy80qr">
<label for="blog_public_off" class="checkbox">
<input type="radio" value="0" name="blog_public" id="blog_public_off" ffpdm="gil0ltqsbd06z4p0dx72pk">
- the error message displayed on that page was not descriptive enough. It only said “Sorry, that site already exists!” without specifying which field it related to (‘site name’? ‘site title’? both?). Also, when the error is detected and the message is displayed on the page, the focus stays on the ‘Create site’ button, which means that screen reader users will now know what is happening, and why the form hasn’t been submitted. Either the error message should be displayed in a modal window, or the keyboard focus should be moved to the top of the error message. Otherwise screen reader users will have to go back to the form and investigate what has happened.
Add new user page
- just like on the “My sites” page, the main content was placed in the HTML table for presentational purposes. This creates unnecessary noise for screen reader users, as the screen reader read out the field’s label, its position within the table, and the corresponding header cell (the label again), for example: “role, row two, role combo box ‘subscriber’ collapsed”. Ideally, CSS should be used for layout purposes and not HTML tables. If this is necessary though, role=”presentation” could be added to tables used for layout (table role=”presentation” […]></table).
In that way the screen readers will ignore the table mark-up when reading out the content;
- when required fields were left empty, the form was not submitted, but no error messages were displayed. The problematic fields were only identified using colour, and so visually impaired people will not be aware of the identified errors and which fields they have occurred in.
- ‘custom date format’ and ‘custom time format’ input fields were missing labels. Each of them should have a label, for example: ‘enter date format’ (which can be hidden from view);
- labels for radio buttons had no ‘for’ attribute;
- please note that screen readers will ignore the additional information displayed under / next to the form fields while in form (application) mode. You could consider adding aria-describedby attribute to each form field with additional information, pointing at the element containing that information, for example:
input type="email" class="regular-text ltr" value="emailaddress" id="new_admin_email" name="new_admin_email" ffpdm="zovnc9anu1pi7qxdkwcjrh" aria-describedby="new_admin_email_info">
p id="new_admin_email_info" class="description">This address is used for admin purposes.......</p>
Jeff de Wit
On the Network Settings page(/wp-admin/network/settings.php) you can set the “Site upload space”. ChromeVox tells me that “Limit total size of files uploaded to” is a checkbox and whether it’s checked or not. Only after I tab to the next field will it announce the input field to me as “100 MB, edit text – size in megabytes”.
There’s no continuation or link between the file size input field and the checkbox that sets that limit.
To ensure that users will hear the text after the input field is announced by the screen reader, use aria-describedby. When the user tabs into the input element the label and paragraph text will be voiced by the screen reader.
Add for and id attributes to implicit labelling to ensure that older AT’s can interpret the label/input relationship.
Some labels were still missing, this is already reported with the ticket during this week. The rest will follow this week.