-
-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessibility: Comply with WCAG 2 #10795
Labels
accessibility
Related to accessibility
desktop
All desktop platforms
enhancement
Feature requests and code enhancements
high
High priority issues
mobile
All mobile platforms
Comments
personalizedrefrigerator
added
enhancement
Feature requests and code enhancements
mobile
All mobile platforms
desktop
All desktop platforms
high
High priority issues
accessibility
Related to accessibility
labels
Jul 29, 2024
personalizedrefrigerator
changed the title
Accessibility metaissue: Comply with WCAG 2.0
Accessibility: Comply with WCAG 2
Jul 29, 2024
This was referenced Jul 29, 2024
personalizedrefrigerator
added a commit
to personalizedrefrigerator/joplin
that referenced
this issue
Aug 3, 2024
This pull request improves focus handling in the **Markdown editor**'s toolbar. See laurent22#10795.
personalizedrefrigerator
added a commit
to personalizedrefrigerator/joplin
that referenced
this issue
Aug 28, 2024
This was referenced Aug 29, 2024
This was referenced Sep 13, 2024
Merged
personalizedrefrigerator
added a commit
to personalizedrefrigerator/joplin
that referenced
this issue
Oct 7, 2024
personalizedrefrigerator
added a commit
to personalizedrefrigerator/joplin
that referenced
this issue
Oct 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
accessibility
Related to accessibility
desktop
All desktop platforms
enhancement
Feature requests and code enhancements
high
High priority issues
mobile
All mobile platforms
Summary
[ Progress: Desktop ] | [ Progress: Mobile ]
This issue tracks general accessibility issues in Joplin mobile and desktop and its progress on WCAG 2.2 compliance.
About the WCAG
The WCAG (Web Content Accessibility Guidelines) is a set of guidelines for improving web accessibility.
The WCAG is divided into success criteria. Each is labelled with "Level A", "Level AA", or "Level AAA". These correspond to different conformance levels.
Conformance levels
There are three different conformance levels1:
According to WebAIM.org2,
The WCAG's definition of the different conformance levels1 confirms WebAIM's statement that Level AAA is not always achievable:
Note
It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
Based on the above, for now, this issue targets Level AA conformance with the WCAG.
This issue: General tasks
Notes: In this issue, different task priorities are marked differently. For example,
Note
The tasks below are a work-in-progress and based on the WCAG 2.2 spec. Completing the tasks below does not guarantee compliance with the spec.
Desktop
Recent relevant changes: #9982, b108bf7, dd5240d, 4827d0b
1. Perceivable
Summary: All non-decorative components of the user interface should be described in a way perceivable to the user.
1.1.1 Non-text content (Level A)
To meet this requirement, all inputs controls and inputs must be labeled.
Tasks:
1.2.1. Audio-only and Video-only, 1.2.2. Captions (Prerecorded), and 1.2.3. Audio Description or Media Alternative (Prerecorded)
Joplin allows users to include prerecorded audio and video in notes. When included as a link (e.g.
[link](:/resourceidhere000000000000000000)
), the generated HTML video element has no associated description.In the desktop app, we should:
video
s andaudio
elements?Also see the spec for related tasks.
1.3 Adaptable
Summary: Content must be presentable in different ways without losing information.
1.3.1. Info and Relationships
role=search
?role=main
?role=navigation
.aria-labelledby
(or perhapsaria-label
) for groups and landmarkslabel
elements to label form controlsNote: This is important even if the icons are hidden from a screen reader — some accessibility tools replace fonts on a page for readability. Marking icons created from a font as such should prevent these accessibility tools from treating them as text.
Effect: It's currently impossible or difficult to tell whether some item is a subsection of another.
aria-level
along with thetree
pattern.aria-errormessage
to associate the error message with the input on the "Keyboard shortcuts" page.::before
or::after
to include non-decorative content (see F87)?Also:
role=
).aria
information (e.g.aria-controls
).1.3.2. Meaningful Sequence
flex-order
or similar order-changing CSS. Are we usingflex-order
anywhere? See F1.1.3.3. Sensory Characteristics
Note: §1.4 covers color guidelines.
This task refers to instructions.
For example, "press the red button in the bottom right corner of the screen to edit" would be bad.
We should:
1.3.4. Orientation
Currently, Joplin doesn't restrict devices to a single orientation. However, it may be difficult to use the desktop app on a phone-sized device in portrait mode. In particular, without moving the sidebars from "View" > "Change application layout".
1.4 Distinguishable
Color for distinguishing content (§1.4.1, A):
Minimum contrast (§1.4.3, AA):
Note: It might not be necessary to improve contrast of inactive buttons (despite having low contrast). See discussion and "incidental" in §1.4.3.
Resize text (§1.4.4, AA):
Avoid images of text unless customizable/essential (§1.4.5, AA):
SubNotebooks.png
, which includes text that isn't presented elsewhere.Note: See the WCAG spec for §1.4.6-1.4.9 (all level AAA).
1.4.10: Reflow (AA)
1.4.11: Non-text contrast (AA)
1.4.12: Text spacing (AA)
Users should be able to override Joplin's styles (through OS accessibility settings?) in the following ways and still use the app:
In particular, content should not be clipped.
1.4.13: Content on Hover or Focus (AA)
When content (e.g. tooltips) can be shown by hovering with the mouse pointer, it should also be possible to show them with a keyboard.
At present, this isn't possible with most
title=
tooltips (at least on Linux). However, the WCAG includes an exception that might be relevant here:As an Electron app, however, Joplin is the user agent, and so this might not apply.
2. Operable
2.1.1. Keyboard
2.1.2. No Keyboard Trap
2.1.3. Keyboard (No Exception) (AAA):
Equivalent to §2.1.1, but removes exceptions.
2.1.4. Character Key Shortcuts (A)
If there are unmodified keyboard shortcuts implemented with just a letter/punctuation/special character, then at least one of the following must be true:
2.2. Provide users enough time to read and use content
§2.2.1: This section seems to be mostly concerned with auto-log-out/locking. I don't believe that Joplin puts a time limit on any activities.
2.2.2. Pause, Stop, Hide
This includes:
§2.2.3-2.2.6 (Level AAA): Concerned with interruptions and timing.
2.3. Seizures: Don't design content in a way that is known to cause seizures
2.4. Navigable
2.4.1. Bypass Blocks (Level A)
Joplin currently has menu items and keyboard shortcuts to jump focus to the note list, sidebar, note title, and note editor (Go > Focus > ...).
2.4.2. Page Titled (Level A)
2.4.3. Focus Order (Level A)
Related (§2.4.3): #10817
2.4.4. Link Purpose (In Context) (Level A)
aria-labelledby
attribute?2.4.5. Multiple Ways (Level AA)
2.4.6. Headings and Labels (Level AA)
<h1>
/etc. tag for the "NOTEBOOKS" heading. This heading, however, seems descriptive.2.4.7. Focus Visible (Level AA)
<select>
elements -- Desktop: Accessibility: Make keyboard focus visible for dropdowns #111772.4.9. Link Purpose (Link Only) (Level AAA)
Based on the "sufficient techniques" section and the "ambiguous to users in general", this seems to be primarily targeted at screen reader users (e.g. when cycling through the links available on a page). To meet this, we might start by:
Also to research:
2.4.10. Section Headings (Level AAA)
Given the second note above, this section likely applies mostly to Joplin's welcome notes and settings screen. At present, the welcome notes use headings.
2.4.11. Focus Not Obscured (Minimum) (Level AA)
2.4.12. Focus Not Obscured (Enhanced) (Level AAA)
2.4.12 is equivalent to 2.4.11, but removes exceptions. See the task list for § 2.4.11.
2.4.13. Focus Appearance (Level AAA)
See also §2.4.7.
2.5.1. Pointer Gestures (Level A)
Drag and drop for notes:
[❗] Support moving notebooks without drag and drop (context menu) -- Desktop: Accessibility: Add "Move to" context menu action for notebooks #11039
2.5.2. Pointer Cancellation (Level A)
Note dragging: Dragging the note back to its original location cancels the action.
Notebook dragging: Dragging a notebook back to its original location (before lifting the pointer) cancels the action.
[🟡] Clicking on a dialog's dimmed background seems to only be cancellable by dragging the pointer outside the main Joplin window.
- Clicking and dragging the dialog's dimmed backdrop into the main dialog content still causes the dialog to close.
Note
A search for
mousedown
andpointerdown
in Joplin's GitHub repository results in very few matches:mousedown
event for the editor's plugin compatibility layer.pointerdown
This suggests (but does not imply) that Joplin desktop doesn't directly handle pointer down events.
2.5.3. Label in Name (Level A)
2.5.4. Motion Actuation (Level A)
Joplin for desktop seems to not have functionality that can be activated by device motion (e.g. accelerometer).
2.5.5. Target Size (Enhanced) (Level AAA)
A non-exhaustive list of items that would need adjustment to implement this:
2.5.6. Concurrent Input Mechanisms (Level AAA)
2.5.7. Dragging Movements (Level AA)
Based on the description of §2.5.1, satisfying 2.5.1 seems to imply that 2.5.7 is also satisfied.
Note that the extended description of this section states:
...and later...
For now, see the checklist for §2.5.1.
2.5.8. Target Size (Minimum) (Level AA)
3.1.1. Language of Page (Level A)
For HTML, H57 recommends using the
lang
attribute. Among other reasons, this is so thatlang
attribute to match Joplin's current locale -- Desktop: Accessibility: Declare app locale with the HTML lang attribute #11218.3.1.2. Language of Parts (Level AA)
lang="en"
.To-do
Mobile
Prior accessibility work and related issues: #10122, #10253, #8715
General notes:
react-native-ama
's documentation includes accessibility checklists specific to React Native that might be helpful.Uncategorized/external keyboard: TextInput blocks focus (Keyboard accessibility issues on Android (TextInput but also beyond) facebook/react-native#45801)
[🔎] Evaluate the mobile application and create a task list based on the WCAG 2.2 spec.
2.2. Provide users enough time to read and use content
Notes on accessibility testing
Screen reader testing
For items related to screen reader accessibility, I'm testing primarially with the following screen readers:
Mobile: Finding contrast issues
On Android, the Accessibility Scanner may also be helpful in identifying and fixing certain accessibility issues (e.g. contrast, unlabelled content).
Footnotes
https://www.w3.org/WAI/WCAG22/Understanding/conformance#conf-req1 ↩ ↩2
https://webaim.org/standards/wcag/#current ↩
The text was updated successfully, but these errors were encountered: