Inkbunny accessibility report

Written by Kimberly Grey — berly.kim
22 May 2022

Preamble

This is a brief overview of accessibility issues that I identified on the Inkbunny website, when I reviewed a random sample of pages on the 22nd of May, 2022. These issues were identified using a combination of automated and manual tests using common web browsers and assistive technologies (AT).

The pages reviewed included:

• The homepage.
• The member’s listing page.
• The login page.
• Various user profile pages.
• Various submission pages.

The report is not intended to be thorough or authoritative, but as a starter guide of issues and improvements that could be made.

These issues are mapped to version 2.1 of the Web Content Accessibility Guidelines (WCAG), a set of accessibility criteria curated by the Web Accessibility Initiative (WAI) at the W3C. WCAG criteria are split into three ‘levels’ of compliance:

• Level A: Considered to be the bare minimum necessary for accessibility compliance.
• Level AA: An ‘acceptable’ level of compliance. This level is specifically referenced by various governments (including those of the US and UK) as their baseline for compliance with equality legislation.
• Level AAA: Maximum compliance. This is generally only considered necessary for services that explicitly cater to disabled and special needs individuals.

Today, I only checked for compliance against levels A and AA. This doesn’t mean that Inkbunny wouldn’t benefit from also incorporating aspects of level AAA, just that I did not include those criteria in the audit.

Also be aware that a new version of WCAG, version 2.2, is currently being finalised for release later this year. I haven’t included those criteria in the body of the report, but have included some in the ‘Other recommendations’ section.

It’s also important to note that these are guidelines. There may be situations where technical limitations or the nature of a feature makes it impossible to make accessible. In these situations it’s recommended to list these as known issues in an accessibility statement.

Finally, I ask that you please take this report in the constructive manner it’s intended in. I’m more than aware that Inkbunny is built and maintained by volunteers, and I’m not attempting to discredit the site or those who work on it. Many, many websites, large and small, get accessibility wrong, and Inkbunny is not exceptional for the failures it has. I just want the fandom’s websites to be better!

If you have any further comments or questions about the content of this report, feel free to contact me through whatever means you prefer. I can provide simple code examples too, if desired.

Overview

My understanding is that Inkbunny, from a design and front-end code perspective, has remained largely unchanged for much of the last decade. Consequentially, the site lacks certain features that are now considered de facto standards, such as having a responsive design or utilising semantic HTML features.

This unfortunately does impact the ability for Inkbunny to be accessibility compliant as it’s fundamentally limited in what devices are able to easily use the website and how assistive technologies are able to understand pages. It is unlikely that Inkbunny will realistically be able to meet the Level AA criteria without significant rework of both the design and front-end elements of the website.

Despite this, there are places where improvements can be made with relatively little modification, and some improvement is better than no improvement at all.

I have chosen to exclude certain issues specific to submissions themselves. I realise it’s potentially unreasonable to require users to provide text descriptions of images, transcripts of audio, and so on.

WCAG failures

Pages lack semantic markup

Multiple pages lack semantically appropriate markup.

Examples:

• None of the homepage sections (‘Popular’, ‘Music’, ‘News’, etc.) are marked up as individual sections, nor are any of the headings marked up as heading elements.
• Section headings on profile pages are also not appropriately marked up.
• Lists (journals, images, watchers, comments) are not marked up as lists.
• Key-value content, such as profile stats and contact links, are not marked up as description lists.
• Various elements (pagination elements, login page, members page) are marked up as being data tables.
• The form labels on the login form aren’t marked up as form labels.

Having semantic HTML present would help assistive technologies from interpreting the structure and content of the page, and allow users to jump directly to the sections they’re looking for.

Relevant guideline: 1.3.1 Info and Relationships (Level A)

Poor colour contrast for thumbnail metadata

The titles and user information that appears under thumbnails (such as on the homepage) has insufficient contrast with the background. The minimum contrast expected is 4.50:1.

Examples:

• On the top-most homepage section, text is displayed in #555555 against a background of #2e3436, resulting in a contrast ratio of 1.70:1.
• On profile page favourite section, text is displayed in #aaaaaa against a background of #d3d7cf, resulting in a contrast ratio of 1.59:1.

This makes it difficult for users with vision impairment or colour blindness to be able to read the text.

Relevant guideline: 1.4.3 Contrast (Minimum) (Level AA)

No language defined

The website’s <html> element does not have a lang attribute indicating what language the site is in.

This prevents assistive technology, particularly screen readers, from understanding what language the content should be announced in.

Relevant guideline: 3.1.1 Language of Page (Level A)

Design cannot reflow in response to zooming

The current design, being non-responsive, is unable to reflow if a user zooms into the page, introducing a horizontal scrollbar.

This makes it more difficult for visually impaired users to read small text, which is a prominent issue due to the small default font size used on Inkbunny. It additionally limits what devices a user may access the website on.

Relevant guideline: 1.4.10 Reflow (Level AA)

Non-descriptive link text

The same text is used to link off to various areas of the website.

Examples:

• There are multiple links on the homepage that use the text ‘See more’, ‘Read more’, or ‘See all’, however these links do not indicate what the user will see more/all of.

This makes it more difficult for assistive technologies to determine what a link does and prevents voice control users from easily selecting the link they want. This will also frustrate screen reader users who are navigating in links mode, as several links will be listed identical text.

Relevant guideline: 2.4.4 Link Purpose (In Context) (Level A)

Invalid HTML is used

The HTML structure in use on Inkbunny is not valid. Currently, all page content is contained within the <html> element, with no delineation between the head (where metadata for the page exists) and the body (the content).

In this situation, the browser has to determine where the delineation exists, and appears to have placed it before the first <input> element instance (as this element existing in the head would be invalid, it assumes we must now be in the body). However, several more elements that can only be used in the head (such as <link> and <meta>) appear later on, creating a messy and invalid HTML structure.

This makes it difficult for assistive technologies to parse and understand the page.

Relevant guideline: 4.1.1 Parsing (Level A)

Images lack text alternatives

Certain images do not have alternate text specified.

Examples:

• The ‘RTA’ graphic in the footer of each page does not have alternative text.

This means the image is inaccessible to screen readers.

Relevant guideline: 1.1.1 Non-text Content (Level A)

No skip links are present

Skip links are (usually) hidden links present at the top of a page which allow assistive technology users to skip past repetitive content, such as a header and navigation, to go directly to the content of a page.

Inkbunny currently does not have any skip links, making it more frustrating for assistive technology users to navigate around the website.

Relevant guideline: 2.4.1. Bypass Blocks (Level A)

Header/link with no text content

I’m not sure if this is used for some other purpose, but every page appears to have a H2 heading element (.banner_panel) with the only content being a link with no text content.

This is frustrating to keyboard navigation users and screen readers, and technically a WCAG failure.

Relevant guidelines: 2.4.4 Link Purpose (In Context) (Level A), 2.4.6 Headings and Labels (Level AA)

Use of inline CSS styles

Inline CSS styles are present throughout the site’s HTML.

This makes it harder for users to specify their own styles, which they may need to do to make content easier to read or to specify high contrast colours.

In situations where dimensions have been hardcoded into a component, such as in submission metadata, this could be considered a WCAG failure, as this prevents users from being able to resize text without it being truncated or made unreadable.

Relevant guideline: 1.4.4 Resize text (Level AA)

Toggle controls aren’t related to their toggled content

User interface elements which control the visibility of others, such as the ‘show’ links on submission metadata and on lists of tags, do not have a relationship with their related elements defined in HTML or with ARIA, nor do they indicate the current state of those elements.

This is inaccessible for screen reader users, as they will not be aware that the control has done anything.

Relevant guideline: 1.3.1 Info and Relationships (Level A)

Logo and background switching controls cannot be used with keyboard

The logo and background switching controls are only usable with a mouse. They cannot be focused on or activated when navigating with a keyboard.

The logo switcher only appears on hover, whereas the background switcher is not built using focusable elements.

This makes them unusable for users using keyboard navigation. The logo switcher is additionally inaccessible on touchscreen devices.

Relevant guideline: 2.1.1 Keyboard (Level A)

Several form inputs don’t have labels

The username, password and email fields on the login page have visible labels, however these labels are not linked to the inputs.

Additionally, the search input on the members page does not have a label.

This means assistive technologies will not announce what the inputs are for, as it has no way of knowing. For example, VoiceOver on macOS only announces that the login page has four empty text inputs.

Member filters activate on input change

The select dropdown filters on the members list page submit immediately upon being changed, causing the page to refresh.

This is disorienting for assistive technology and keyboard navigation users, as they have no initiated a page refresh and their position on the page has been reset.

This is also a general accessibility issue in some browsers, as it isn’t possible to navigate through select dropdowns without activating a change event.

Relevant guideline: 3.2.2 On Input (Level A)

Other recommendations

Many pages lack a primary heading

It is generally recommended, for the purposes of both accessibility and SEO, that all pages use the H1 to describe the page’s content, for example ‘[user]’s profile’ or ‘[image name] by [user]’.

This makes it easier for assistive technology users to understand the purpose and content of the page.

Currently, all pages use the ‘Inkbunny’ name for the H1 heading.

Relevant guidance: Providing descriptive headings

No custom focus style

Inkbunny currently uses the browser’s default focus style when navigating by keyboard.

Whilst this meets the current guideline, a new guideline—2.4.11 Focus Appearance (Minimum) (Level AA)—is being introduced in WCAG 2.2, and you may wish to provide a custom focus style that meets the necessary contrast requirements.

Font size is very small

Large quantities of UI text on Inkbunny is very small, such as stats on user profiles, lists of watchers, thumbnail metadata, contact link headers, footer links, and more, which are displayed at 8 point (or 10.666 pixels).

There isn’t a WCAG guideline for minimum font size, as the minimum size needed for legibility is different depending on the alphabet and typeface being used.

For a simple sans-serif font in English, as used on Inkbunny, my recommendation would be to only drop as low as around 14 pixels except for minor text, such as legal copy, as it can be difficult for users to read large amounts of very small text.

Control targets are very small

Relatedly, many controls have very small target areas, with some (such as footer links and the help links in submission metadata) as small as 13 pixels in both dimensions.

These are very difficult for users with physical tremors or users of coarse input methods (such as touchscreens or switch controls) to be able to use reliably.

There isn’t currently a WCAG guideline for minimum target size, however a minimum of 24 pixels in both dimensions is being introduced in WCAG 2.2: 2.5.8 Target Size (Minimum) (Level AA). Note that this is 24 pixels including negative space around the target.

The human interface guidelines for most systems go above this and recommend larger minimum sizes, such as Apple’s 44 pixels.

Use of titles to label graphical buttons

Various elements of Inkbunny’s UI, including profile statistics, the main navigation links, logo and background switchers use title attributes to explain their function or meaning.

This is not advisable, as the tooltips that title attributes create cannot be read on touchscreen interfaces, do not respect zoom settings, and can be difficult for users with motor issues to make appear, especially if the button is fairly small.

In the case of the switchers, these buttons are also unusable for people using voice control mechanisms, as they have no visible name to refer to the buttons by.

In the case of the main navigation, I note that each button has the text of the button included within it, but hidden using a display: none style. This text is actually still inaccessible to screen readers, as they do not read content that has been hidden in this way. Use the visually-hidden pattern instead.