Skip to content

Commit fc2f24c

Browse files
authored
Merge pull request #130 from data-derp/feature/accessibility
Add accessibility content
2 parents 9f8e626 + 889dffe commit fc2f24c

File tree

9 files changed

+348
-1
lines changed

9 files changed

+348
-1
lines changed

src/components/Authors.js

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,18 @@ const baseAuthors = {
3737
title: "Curator",
3838
url: "https://github.com/petershaw",
3939
imageURL: "https://github.com/petershaw.png"
40+
},
41+
knut: {
42+
name: "Knut Gravel",
43+
title: "Contributor",
44+
url: "https://github.com/qutax",
45+
imageURL: "https://github.com/qutax.png"
46+
},
47+
marius: {
48+
name: "Marius Hilleke",
49+
title: "Contributor",
50+
url: "https://github.com/marius-tw",
51+
imageURL: "https://github.com/marius-tw.png"
4052
}
4153
}
4254

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"label": "Making data accessible",
3+
"position": 9
4+
}
21.6 KB
Loading
58.7 KB
Loading
Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
---
2+
sidebar_position: 2
3+
minutesToComplete: 5
4+
---
5+
6+
# Graphical visualization
7+
8+
As stated above graphs can be one form to visualize data. Especially for those there are some criteria which can be
9+
considered regarding the design or the technical integration of the graphs on a web-based interface.
10+
11+
## Design choices
12+
13+
### Keeping it simple
14+
15+
“Data graphics should draw the viewer’s attention to the sense and substance of the data, not to something else. []
16+
- Edward Tufte; [The Visual Display of Quantitative Information](https://www.edwardtufte.com/tufte/books_vdqi)
17+
18+
- Reduce clutter.
19+
- Avoid animations (and if they are necessary, provide a way to turn them off).
20+
- If possible: offer a light and a dark version (e.g., for people who are sensitive to bright colors).
21+
- Using scalable image formats such as SVG helps users to increase and decrease the size of the image without loss of detail/information.
22+
23+
![A comparison of two graphs. The left graph is a simple 2D bar chart with only the most basic elements. The right graph is presented in 3D with shadows. It is hard to see which value the bars reach in the right graph](./assets/image2.png)
24+
25+
### Colors
26+
27+
Due to the fact that [around 300 million people have color-deficient vision](https://www.colourblindawareness.org/),
28+
considering the choice of color can be crucial for the accessibility of visualizations.
29+
30+
### Contrast
31+
32+
* Use contrasts / different shades instead of multiple colors
33+
* A suggested level of contrast ratio for objects is 3:1
34+
* Tools exist that can be used for checking the contrast of two colors manually:
35+
* [Contrast Checker by WebAIM](https://webaim.org/resources/contrastchecker/)
36+
* [Contrast Ratio by Siege Media](https://www.siegemedia.com/contrast-ratio)
37+
38+
Some challenges might still remain:
39+
40+
* Using a color palette might comply with required contrast ratios but on the other hand might distract the focus in charts from the most important information for the user (e.g. when different colors are used for error-events in a stacked bar-chart)
41+
42+
### Conveying meaning
43+
44+
* If colors convey meaning, provide additional ways of differentiating
45+
* Tools for that can include symbols, labels, patterns, texture, icon, text or overlay
46+
* The disadvantage of additional patterns or elements in the visualization can be that it will make it even more difficult to read the information in a visualization, therefore one should avoid adding too much [chartjunk](https://en.wikipedia.org/wiki/Chartjunk).
47+
48+
![A simple example of a pie chart where patterns are used in addition to colors to keep the areas visually apart and label them.](./assets/image1.png)
49+
50+
> **Disclaimer**: this example image is only for illustrating the usage of patterns in addition to colors. However, it is not a good example for a chart in general. There are better ways to label charts, and the patterns and colors can be distracting instead of helping.
51+
52+
53+
### Alternative texts and descriptions
54+
55+
* Provide short, concise alternative texts.
56+
* There is no universally applicable alternative text for an image. The context matters.
57+
* If applicable, provide a longer description, e.g. below the image.
58+
* Don't start the text with "an image" or "a picture". Screen reader users already know this, because you're using the HTML image element.
59+
60+
### More resources & examples
61+
62+
* [Harvard University: Write helpful Alt Text to describe images](https://accessibility.huit.harvard.edu/describe-content-images)
Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
---
2+
sidebar_position: 1
3+
minutesToComplete: 2
4+
authors: [knut, marius, tklae, kris]
5+
---
6+
7+
# Overview
8+
Visualizing data using tables, graphs, videos, or images can help in making the data itself or stories and takeaways
9+
related to it more accessible.
10+
However, these tools can also have the opposite effect for some users, making the output we provide less accessible.
11+
This is why it is important to know our audience. Who is going to access our graphs? Where are they integrated? Will
12+
the content be shared with others?
13+
14+
## Diverse abilities, disabilities, and barriers
15+
[People have different abilities, skills, and preferences](https://www.w3.org/WAI/people-use-web/abilities-barriers/).
16+
So it's safe to say that they behave and interact with interfaces—and data presented—differently.
17+
18+
Examples for different kinds of disabilities (non-exhaustive list):
19+
- Visual (e.g. color blindness)
20+
- Cognitive, learning, and neurological (e.g. dyslexia)
21+
- Physical (e.g. parkinson's disease)
22+
- Auditory (partial or total inability to hear)
23+
- Speech (e.g. stuttering)
24+
25+
Features that provide accessibility to some might be inaccessible to others and it is also possible that a person has a combination of disabilities, e.g. deaf-blindness (including partial loss of sight and hearing).
26+
The two-senses or multi-sensory principle can help increase accessibility: make information perceivable by at least two senses.
27+
28+
## Required by some, helpful for others
29+
Accessibility features can be helpful for everyone. Even some everyday objects were actually invented as tools for accessibility, like the electrical toothbrush, or vibration alarm for mobile phones. Similarly, accessibility features for digital content can increase the usability for all users, for example by providing closed captions for videos, or providing audio for long texts.
Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
---
2+
sidebar_position: 4
3+
minutesToComplete: 2
4+
---
5+
6+
# Tables
7+
8+
## Keeping it simple
9+
10+
* Try to keep your tables as simple as possible.
11+
* The most simple table should have one row or column header.
12+
* If the data itself is complex, think about whether it’s possible to split it into multiple tables. This might also increase accessibility on mobile devices.
13+
14+
### Use semantic HTML
15+
16+
* If you’re publishing your tables on the web, use semantic markup for creating your tables.
17+
* **Good:** Using `<table>`, `<tr>`, `<th>`, `<td>,` and other table markup to present tabular data.
18+
* **Bad:** Using non-semantic HTML like `<div>` instead, just styling it like a table.
19+
Lines changed: 221 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,221 @@
1+
---
2+
sidebar_position: 3
3+
minutesToComplete: 15
4+
---
5+
6+
# Text accessibility for data engineering and presentation
7+
8+
When working with or presenting data or data related information, it's a good idea to adhere to proven accessibility
9+
principles. These standards are inspired by web design accessibility practices as well as standards from print to
10+
ensure that all users, including those with disabilities, can access and comprehend the content we present.
11+
12+
Text accessibility focuses on making written content easy to read and understand for everyone, regardless of their
13+
physical or cognitive abilities. This includes considering visual impairments, cognitive challenges, and language
14+
barriers.
15+
16+
Let's have a look at different elements of text accessibility, provide practical guidelines for improving the
17+
readability and usability of our content, and explain why each point is important.
18+
19+
## Text Size and Adjustability
20+
21+
### Size Matters
22+
23+
The size of the presented text is fundamental to accessibility. Small text can be difficult to read, especially for
24+
users with visual impairments. Larger text is easier to read, reducing eye strain and making it accessible to a wider
25+
audience.
26+
27+
It can be helpful to give context to the data, without context you may lose your audience. Delight your readers with
28+
easy-to-read texts and don't tire them out.
29+
30+
This applies both to descriptive content and to legends, notes and information.
31+
32+
### Adjustable Text Size
33+
Allowing users to change the text size to suit their preferences is essential. This supports users with varying degrees
34+
of visual impairment and those who prefer larger text for comfort. Text resizing should not break the layout of your
35+
presentation. Remember that the text should enrich your data and diagrams, so they should be in focus. Consider
36+
resizing these elements along with the text.
37+
38+
- **Good Example**: Using relative units like `font-size: 1em;` so users can adjust text size via browser settings.
39+
- **Bad Example**: Using fixed units like `font-size: 12px;` which doesn't scale with user preferences.
40+
41+
## Choosing the Right Font
42+
43+
### Font Selection
44+
The type of font used can significantly impact readability. Sans-serif fonts, such as Arial, Helvetica, and Verdana,
45+
are generally easier to read on screens compared to serif fonts. Avoiding overly decorative fonts ensures the text is
46+
straightforward and readable.
47+
48+
There are also fonts that are specifically designed with accessibility in mind, such as "[Atkinson Hyperlegible](https://brailleinstitute.org/freefont)" or "[OpenDyslexic](https://opendyslexic.org/)".
49+
50+
- **Good Example**: Using a Sans-serif font for body text.
51+
- **Bad Example**: Using a decorative font like Comic Sans or a complex script font for body text.
52+
53+
### Formatting for Clarity
54+
Text formatting should be clean and straightforward. Adequate line spacing and high contrast between text and
55+
background enhance readability, particularly for users with visual impairments or dyslexia. But even for those who
56+
read for longer, it becomes less tiring to read texts with high contrast.
57+
58+
- **Good Example**: Text with line spacing set to 1.4 and high contrast colors (black text on a white background).
59+
- **Bad Example**: Text with minimal line spacing and low contrast colors (light gray text on a white background).
60+
61+
## Consistency and Clear Markup
62+
63+
### Consistent Markup
64+
Using consistent markup for headings, paragraphs, lists, and other elements helps screen readers understand the
65+
structure of the content. This aids navigation and comprehension for users relying on assistive technologies. Keeping
66+
this in mind, it also helps you to write information in a structured order that leads to better understandable content.
67+
68+
- **Good Example**: Using `<h1>` for the main title, `<h2>` for section headings, and `<p>` for paragraphs.
69+
- **Bad Example**: Using `<div>` tags with classes to style text, without semantic meaning.
70+
71+
### Concise and Understandable Formatting
72+
Keeping the text concise and to the point makes information easier to digest. Using bullet points and numbered lists
73+
breaks up large blocks of text, which is beneficial for all users, especially those with cognitive impairments.
74+
75+
- **Good Example**: Using bullet points for lists and keeping paragraphs short.
76+
- **Bad Example**: Long, unbroken paragraphs filled with complex sentences.
77+
78+
Distinguish between ordered and unordered lists to provide structural information about the content.
79+
80+
## Language and Target Audience
81+
82+
### Language Settings
83+
Setting the language of the presentation (eg. a web page) correctly using the lang attribute in HTML helps screen
84+
readers pronounce words correctly and provides context for translations. This also applies to PDFs and other formats.
85+
This improves the experience for non-native speakers and those using translation tools.
86+
87+
- **Good Example**: `<html lang="en">`
88+
- **Bad Example**: `<html>`, without specifying the language.
89+
90+
Pay attention to the metadata of the elements and of the overall document. They are just as important as the content
91+
itself. Especially when a reader uses technology to support the eyes.
92+
93+
### Supported Translations
94+
Knowing your audience and where they are coming from helps to determine if the content should be translated and which
95+
languages should be supported. Accurate translations ensure that non-native speakers can understand and engage with
96+
your content just as well as native speakers.
97+
98+
In times when we are close to the babelfish, this requirement increases. Make sure that your text can be translated
99+
automatically.
100+
101+
- **Good Example**: Providing content in multiple languages written by native speakers (if possible).
102+
- **Bad Example**: Offering no translation or only poor machine translations that are difficult to understand.
103+
104+
Providing texts in e.g. fluent English and fluent Spanish improves the possibility of translating the same text into
105+
e.g. Japanese, as the meaning of the words is more accurate than if the text is written only by a native English speaker.
106+
107+
### Depth of Explanations
108+
Providing explanations that match your target audience's knowledge level is crucial. Offering expandable sections or
109+
links to more detailed information caters to both novice and experienced users.
110+
111+
- **Good Example**: Using simple explanations with links to more detailed content.
112+
- **Bad Example**: Using complex explanations without additional context or simpler alternatives or use one large text
113+
- block that repeats itself over and over in boring language.
114+
115+
### Easy Language
116+
Using plain language and short sentences ensures the content is accessible to a wider audience, including those with
117+
cognitive impairments or lower literacy levels. Complex words and sentence structures can alienate or confuse users.
118+
This does not imply that the text must get boring. Sometimes nested sentences don't give more information, but hide
119+
essential information behind clever-sounding phrases.
120+
121+
In certain cases, not using a domain specific language and instead trying to specifically avoid the common words or
122+
names can lead to misunderstandings, especially when talking to a more advanced audience.
123+
124+
- **Good Example**: "The personal information of 20 Million people was stolen in the breach."
125+
- **Bad Example**: "Through a series of using a chain of specific 0-days the intruders were able to obtain PII from
126+
- CRM systems leading to the exposure of a data set of more than 20 Million unique entries."
127+
128+
### Avoiding Jargon and Pop Culture References
129+
Avoiding industry jargon, technical terms, and pop culture references ensures the content is understandable to everyone,
130+
not just experts or culturally specific groups. When it comes to very specific terms or jargon that cannot be avoided,
131+
clear definitions should be provided or further explanations added. When presenting to audiences, we have a tendency to
132+
want to look smart and include more technical terms, even though this might lead to parts of the audience feeling left
133+
out.
134+
135+
- **Good Example**: "We formatted the data in a way to show rainfall in given months in the following graph."
136+
- **Bad Example**: "We dissected the Pandas dataframe using a splice operation to display the rain/month ratio on this
137+
- Plotly polyline mark."
138+
139+
### Explaining Abbreviations
140+
Abbreviations should be spelled out in full the first time they are used to help all users understand them, including
141+
those who may not be familiar with the terms. This practice aids comprehension and inclusivity.
142+
143+
- **Good Example**: "HyperText Markup Language (HTML) is used to create web pages."
144+
- **Bad Example**: "HTML is used to create web pages." (without explaining HTML)
145+
146+
When working with <abbr title="HyperText Markup Language">HTML</abbr>, semantic elements can also be used to describe abbreviations and their meaning, namely `<abbr>`, potentially in combination with `<dfn>`. See also [MDN Web Docs on defining an abbreviation](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/abbr#defining_an_abbreviation).
147+
148+
## Reading Level
149+
150+
### Appropriate Reading Level
151+
Writing at a reading level that matches your target audience ensures that the content is accessible to most users. Tools
152+
like the Flesch-Kincaid or LIX readability tests can help ensure your text is suitable. Generally, content should be
153+
accessible to users with a 6th to 8th-grade reading level. In some instances, it might make sense to provide different
154+
variations of a text for different target audiences but usually it is preferred to provide a single version of the
155+
content that can be understood by everyone.
156+
157+
- **Good Example**: This sentence shows the point when you read it.
158+
- **Bad Example**: This sentence, taken as a reading passage unto itself, is being used to prove a point.
159+
160+
## Text-to-Speech and Navigation
161+
162+
### Text-to-Speech Compatibility
163+
Ensuring your website is compatible with text-to-speech (TTS) software makes your content accessible to users with
164+
visual impairments or reading difficulties. Proper HTML markup
165+
using [semantic HTML](https://www.w3schools.com/html/html5_semantic_elements.asp) ensures TTS programs can accurately
166+
interpret and vocalize the content.
167+
168+
- **Good Example**: Using semantic HTML elements and ARIA labels to enhance TTS functionality.
169+
- **Bad Example**: Using non-semantic tags (like only divs) and lacking ARIA labels, confusing TTS programs.
170+
171+
> Did you know: iOS has an embedded text-to-speech reader you can turn on with a two-finger swipe-down gesture.
172+
> On Android there is also an accessibility function when you hold both volume buttons down for 3 seconds.
173+
174+
### Reader Support and Navigation Jumps
175+
On websites, including features like [skip links](https://www.w3schools.com/accessibility/accessibility_skip_links.php)
176+
allows users to jump directly to the main content, supporting easier navigation for screen reader users and those using
177+
keyboard navigation. Use a descriptive navigation text that precisely describes the content. This improves the overall
178+
user experience.
179+
180+
- **Good Example**: Providing a "Skip to main content" link at the top of the page.
181+
- **Bad Example**: Forcing users to tab through an entire navigation menu before reaching the main content.
182+
- **Bad Example**: Having the tab order set incorrectly which makes users using keyboard navigation jump all over the
183+
- place or start at the bottom of the conent.
184+
185+
## Additional Features
186+
187+
### Summaries and optional content
188+
Summaries at the top and/or bottom of longer paragraphs or the whole content can help to double check if the information
189+
was understood correctly or provide alternative phrasing. Trade-offs have to be made to not repeat the same points too
190+
often or unnecessarily bloat the content.
191+
192+
It has proven to be a good idea to start with a "Management Summary" paragraph stating what the text is all about and
193+
what topics it will cover, and end with a bullet point list summarizing the content.
194+
195+
Content that is optional should be thought about: In some cases it pays of to not include it at all, in other
196+
circumstances it makes sense to keep it but mark it as optional.
197+
198+
### Print Preview
199+
Providing a print-friendly version of your information ensures that all users can easily print and read the content
200+
offline without losing important information. Print stylesheets can format content appropriately.
201+
202+
- **Good Example**: Offering a print stylesheet that formats only the relevant content appropriately for printing.
203+
- **Bad Example**: Printing the whole page as it appears on the screen, which may include unnecessary navigation menus
204+
- and advertisements.
205+
206+
### Following Disability Language Style Guide
207+
The language we use should be respectful and inclusive. Using person-first language and avoiding outdated or offensive
208+
terms helps to create a more inclusive environment.
209+
210+
- **Good Example**: "Person with a disability" (people-first language) or "disabled person" (identity-first language).
211+
- **Bad Example**: "Handicapped" or other outdated terms.
212+
213+
[Link to a disability language style guide](https://ncdj.org/style-guide/)
214+
215+
### Providing Full Link Text
216+
On websites, using descriptive link text instead of vague phrases helps users understand the purpose and destination of
217+
the link. This practice enhances navigation and accessibility, particularly for screen reader users.
218+
219+
- **Good Example**: "Learn more about our accessibility features."
220+
- **Bad Example**: "Click here."
221+

0 commit comments

Comments
 (0)