1. Accessibility
1.1. Pat's dieUX cartoon pages are designed to fulfil the purposes of accessibility research. Some pages mimic popular coding strategies that may deliberately challenge accessibility for some users.
Pat Godfrey“Accessibility is our human right: an inclusive experience should be too.”
VoiceOver for iOS
1.2. People using VoiceOver for iOS should set their screen reader to read the entire page with a two-fingered swipe up. Get help with iOS VoiceOver gestures.
2. Images
2.1. The dieUX cartoon strips are presented in a number of different ways to challenge a variety of web coding and accessibility strategies.
2.2. The strips are chosen for this study as they:
- Contain image texts, which are longer than the 120 characters recommended for alternative texts.
- Are responsive and being wide landscape, the images shrink too small to read the texts from in narrower viewports.
- Have contexts and 'text', the accuracy of which is essential to their understanding and the enjoyment of their humour or irony, etc.
2.3. Where thought correct, images are:
- Given a short alternative text informing of the series, the format, and outline topic area.
- Given
width
andheight
attributes. - Made responsive using the
<picture>
element and CSS styling. - Presented with the
figure
tag. - Accompanied by a
figcaption
element with the cartoon strip heading and descriptive version of the strip.
2.4. Where thought correct, images are optimised for ease of loading and given meaningful file names.
2.6. For the purposes of the study, it may not always be immediately obvious which page is, or is not purposefully accessible or inaccessible. Study participants will report on their experience.
3. Design Patterns
3.1. For the purposes of this study, some design patterns will prove difficult to access. These are based on industry common practice and may, or may not conform to accessibility guidelines or legislation.
3.2. Where thought correct, some patterns are engineered to be highly accessible and may fail under testing.
4. Scripting
4.1. Where thought correct, the accessible content is created to the following mantra:
- HTML for content.
- CSS for presentation.
- JavaScript for functions.
4.2. This mantra ensures:
- JavaScript updates CSS classes and not presentational attributes within the HTML.
- CSS is responsible for all presentation. Certain HTML tags are employed to give emphasis to text including:
<strong>
<em>
<mark>
4.3. Chosen content is sometimes made available only to screen-readers and Braille displays (i.e. made always available to the DOM). This is not to discriminate visual users and only supports cognition for our visually impaired and other users employing assistive browsing technologies.
5. Web Content Accessibility Guidelines (WCAG)
5.1. This website conforms to WCAG 2.1.—even the inaccessible bits! It's kind of the point.
5.2. An exception is the duplicity of the homepage link and site logo link to the homepage. I won't make a scene if you won't?
6. Accessible Rich Internet Applications (ARIA)
6.1. ARIA is employed on the caption toggle button and figcaption
expand and collapse interaction.
6.2. The toggle button is marked, aria-hidden="true"
to negate its appearance in the accessibility tree.
6.3. The rationale under test is that the figcaption
is not hidden from the DOM or accessibility tree, and only visibly hidden. This negates screen-reader users requiring the toggle button, so why bother them with it? It's what is being tested, so your feedback is welcome.
6.4. The outline strategy meets ARIA guidance.
7. User testing
7.1. User tests will be carried out on a variety of users.
7.2. Sighted users will be invited to complete tasks that require access to the content of the cartton strips and other infographics. Certain coding will be tailored to frustrate the task and to simulate the experience of screen reader users.
7.3. In recent research, Pat found that 48 of 50 cartoon websites featured content that was inaccessible to screen-readers or to Braille displays. Given the importance of cartoons to political and social commentry and persuasion, it is only criminal to occlude Assitive Technology users from accessing this most important content?
8. Errors
8.1. Errors are a feature of prototypes. They are what we learn from.
8.2. The following tests have been carried out:
- HTML Validation. Residual 'Warnings' for using
role="navigation"
on<nav>
elements as recommended in some articles discussing screen-reader testing. - WAVE Accessibility Test. There remains an issue with redundant links. This is partially architectural and also partly the dichotomy between using a logo as a Homepage link and adding another Homepage link in copy text for users not familiar with using the logo as the Home link. WAVE likes a target for
<href="#top">
, too, which we know is built in to HTML browsers? - CSS Validation. The definition list deliberately shares a color value between the
<dt>
background and border to key in with the<dd>
style. There is no detriment to the accessibility.
Error Corrections
This cartoon strip is awarded 3-stars of 5.

The intern is left waiting by our senior designer's desk. "Um, Sir?" He starts, "While waiting, I noticed some errors in the reports you left open on your desk." Our designer thinks quickly and says, "Gosh. Can you type?"
The intern brags, "I am an expert typist, Sir". Our designer moves aside and tells the intern, "Here. Take my chair. Bradley, isn't it?"
9. Your Feedback
9.1. When you feel you can improve my accesibility practice then please do reach out to me at inquiries@learningtoo.eu.