Category: Website

Bad example: Timesheet submit button

Author Rachele DiTullioPosted on Categories WebsiteTags , ,

This month at work, we’ve started using new time tracking software for submitting our timesheets. The process for submitting a timesheet in this system is a truly cursed design pattern. Behold, the “Submit Timesheet” button.

screenshot of an expanded panel called Actions that contains button called "Submit Timesheet". Next to this text is a red error icon.

I tried clicking on the “Submit Timesheet” text and nothing happened. I expected this text to be a button because it’s supposed to submit the timesheet, but no, this is not a button.

I asked myself, “Why is there an error icon?”

Then I hovered the mouse cursor over the error icon and saw this:

screenshot of the Submit Timesheet toggle with an error icon on the left side and a green checkmark icon on the right side.

It’s not very obvious, but this control looks like a switch. When I inspected the switch, this is what I saw, simplified:

<div>
<span>Submit Timesheet</span>
</div>
<div>
<label>
<div>Submit Timesheet</div>
<div>
<div>
<input type="checkbox">
<span></span>
</div>
</div>
</label>
</div>

Issues

  1. The switch doesn’t announce the switch role because it is missing role="switch".
  2. The visible label text “Submit Timesheet” is not associated with the switch and the switch doesn’t have an accessible name.
  3. The <label> element is hidden from all users with CSS, meaning no one can click on the “Submit Timesheet” text to operate the switch.
  4. Toggling this switch causes the page to change to a different screen, a violation of SC 3.2.2 On Input.

Please, just use a <button> for submitting forms.

Accessibility testing spreadsheet version 2

Author Rachele DiTullioPosted on Categories Mobile, WebsiteTags ,

I’ve updated the spreadsheet I use for tracking accessibility audits with three big additions.

Download the accessibility testing spreadsheet (Updated 26 January 2024)

WCAG 2.2 success criteria added

I’ve added the six new WCAG 2.2 level A and AA success criteria (SC) to the “WCAG Success Criterion” column in each component’s tab. This brings the total number of SCs for an audit to 55. (4.1.1 Parsing is deprecated but still included for 2.1.) Each new SC is highlighted in light green and includes “NEW in 2.2” in its name.

If you’re not ready to test for WCAG 2.2 SCs, just mark them as N/A.

WCAG failure tracking

I’ve added rudimentary tracking of the number of WCAG violations found for each component which is displayed on the “Scope” tab in the a new “WCAG Violations” column. Each cell counts the number of “Fails” selected in the “Status” column of each component’s tab.

On the “Overview” tab, you can see a running total of all WCAG violations found for all components in the audit.

Prioritizing issues

I’ve also added a “Priority” column to each component’s tab. Each SC can be assigned a priority on a five-point scale:

  1. Critical – Blockers that prevent someone from completing a task, e.g. a button that cannot be used with a keyboard​
  2. High – Issues that present a significant barrier to someone completing a task, e.g. application times out without allowing the user to extend it
  3. Medium – (Most issues) Issues that present a barrier to some users from fully accessing the information or interface, e.g. text has poor color contrast​
  4. Low – Issues that present an unnecessary barrier but do not prevent a user from completing a task, e.g. image text that isn’t sufficiently descriptive​
  5. Best Practice – Issues that present some accessibility barriers but are not considered failures under the Web Content Accessibility Guidelines (WCAG), e.g. using a button instead of a link to open a webpage in a browser

If you have any questions about the spreadsheet or additions you’d like to see, please contact me.

Autocomplete accessibility bookmarklet

Author Rachele DiTullioPosted on Categories Desktop, WebsiteTags , ,

Drag the autocomplete bookmarklet to your bookmarks bar.

I created this bookmarklet for testing WCAG success criterion 1.3.5 Identify Input Purpose (AA) which requires that if an input field requests personal information about the user, we must apply the appropriate autocomplete value to the field. For example, an input field requesting the user’s full name would have an attribute of autocomplete="name". This allows the browser to attempt to autofill the input field with previous values entered for the same information. It is very much browser-specific.

Amazon create account form with a Your Name field. The letters R A are entered into the field and autocomplete shows five variations of the name Rachele DiTullio.
Amazon create account screen in Firefox

This bookmarklet checks the webpage for any input fields that contain the autocomplete attribute. If none are found, it returns an alert message.

a google.com alert message that says No input fields with autocomplete attributes found on this page.
Alert message on the Google search page

If autocomplete attributes are found, the script returns the values and displays them in context of the input field.

A form showing five form fields all with autocomplete values defined.
TPGi.com signup form with autocomplete values

This makes it easy to determine if input fields have autocomplete attributes defined and if they are valid. Click the bookmarklet again to remove the overlay text.