Skip to content

Mobile: Accessibility: Comply with WCAG 2.2 #11661

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.

Sign up for GitHub

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

Jump to bottom
Open
personalizedrefrigerator opened this issue Jan 16, 2025 · 3 comments
Open

Mobile: Accessibility: Comply with WCAG 2.2 #11661

personalizedrefrigerator opened this issue Jan 16, 2025 · 3 comments
Labels
accessibility Related to accessibility bug It's a bug mobile All mobile platforms

Comments

@personalizedrefrigerator
Copy link
Collaborator

personalizedrefrigerator commented Jan 16, 2025 •
edited
Loading

Summary

See #10795 for more information about this task.

Status:

Task Done Total Percent done
Items marked with "[❗]" (Usually Level A items) 37 65 56.9%
Items marked with "[🟡]" (Usually Level AA items) 6 23 26%
Needs research 1 22 4.5%

Notes

Some accessibility work and issues from before starting this project: #10122, #10253, #8715

General notes:

Uncategorized issues:

  • Screen reader: When closing the voice typing dialog, focus jumps to the "back" button at the top of the screen.
  • Screen reader: It seems difficult to act on selected items (e.g. select items, then duplicate) with a screen reader.
    • Proposed fix: Add accessibility actions (using a React Native API) to items in the note list.
  • Screen reader: It seems difficult to navigate to/from the Markdown toolbar using a screen reader.
  • Screen reader: After activating items on the Markdown toolbar, there's no feedback to indicate that an action was completed. (E.g. after clicking "Header 5", it seems unclear whether a header was added/removed and where).
    • A pull request for this was closed (in part due to the complexity of how it got localization to work in the editor). Feedback on whether this should be implemented would be welcome!
  • Screen reader: Missing regions.
    • To-do: Check whether it's possible to add navigation/main/... regions with React Native — the supported accessibility roles seem much more limited than what's available on web. This might be possible with an external dependency.

Note

For now, most of this evaluation focuses on mobile/Android. For keyboard accessibility (unless TalkBack is enabled), React Native has focus issues with its built-in TextInput component.

Checklist

1.1. Text alternatives

1.1.1. Non-text Content (A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
    [ ...other exceptions... ]
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

1.2.1 - 1.2.3. Audio and Video (A)

  • [🔷] Prerecorded audio and video would be user-created (attached as files in notes). While users are currently able to provide their own audio/video transcripts, it may make sense to include an "accessibility check" button that checks for unlabelled audo/video/images. (I think OneNote has this).

Note: §1.2.4-1.2.9 are all related to audio/video recordings/streams, which is not included in Joplin mobile by default.

1.3.1. Info and Relationships (A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Note

If it's not possible to convey certain relationships/structure with React Native, it may be permissible to describe the structure in text:

Some technologies do not provide a means to programmatically determine some types of information and relationships. In that case then there should be a text description of the information and relationships. For instance, "all required fields are marked with an asterisk (*)". The text description should be near the information it is describing (when the page is linearized), such as in the parent element or in the adjacent element.
— https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html

Important

After adding/updating accessbilityRoles, be sure to check that the change improves screen reader accessibility on at least one platform and doesn't degrade screen reader support on other platforms.

Other structure information:

1.3.2. Meaningful sequence (A)

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Note: There are several issues related to this on iOS that may be difficult to resolve without adding a new dependency. For example, "dismiss" actions are sometimes read while navigating menus. However, this document currently focuses on Android accessibility. Many of the iOS issues are not listed here.

  • [❗] [🔎] New note menu: "New note"/"New to-do" buttons are before the "New" button in the focus order -- pressing "New" makes these items focusable, but it isn't necessarily clear that the user should navigate backwards in the focus order to access them. This may need to be changed.

1.3.3. Sensory characteristics (A)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

This guideline seems to apply to instructions for using the app. I'm not aware of mobile app instructions that rely on sensory characteristics. If they exist, however, they're most likely to be in settings screen descriptions.

1.3.4. Orientation (AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

At least on Android, Joplin mobile does not restrict the screen orientation. In the past, however, on iOS, the Modal component's default props (supportedOrientations) have restricted the app orientation.

1.3.5. Identify input purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

  • The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
  • The content is implemented using technologies with support for identifying the expected meaning for form input data.
  • [🔎] [🟡] This section seems to mostly be related to autocomplete in HTML. React Native has the autoComplete attribute for TextInput. Most relevant is likely the new-password autocomplete value. Add correct autoComplete to inputs in settings.
  • [🟡] Ensure that search inputs are marked as search inputs (see also items under "Info and Relationships").

Note: 1.3.6 is level AAA and not included in this document.

1.4. Distinguishable

1.4.1. Use of color (A)

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Note: Syntax highlighting: Joplin's Markdown editor uses syntax highlighting to distinguish content. However, this syntax highlighting is based on the content of the document and should thus not be the "only visual means of conveying information".

1.4.2. Audio control (A)

If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

At present, all audio should be user-created (and only auto-play if this is set by the user in HTML). Additionally, audio included with [](:/resourceidhere) have WebView-provided controls.

1.4.3. Contrast (Minimum) (AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no contrast requirement.

Contrast issues found with the accessibility scanner are listed in the section for SC 1.4.11.

1.4.4. Resize text (AA)

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

If relying on the system zoom level is not sufficient,

1.4.5. Images of text (AA)

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

Aside from icons (which should have labels and are often non-text), Joplin does not use images of text.

1.4.6. - 1.4.9.

SCs 1.4.6-1.4.9 are all level AAA and have been omitted.

1.4.10. Content reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
    Horizontal scrolling content at a height equivalent to 256 CSS pixels.
  • Except for parts of the content which require two-dimensional layout for usage or meaning.
  • [🟡] Fix parts of certain dialogs are clipped offscreen on screens with height 256px -- Mobile: Accessibility: Improve dialog accessibility #11395
  • [🟡] The notebook list cannot be accessed on a screen with height 256px.
  • [🟡] The Markdown toolbar is always hidden on screens with a small height (near 256px).
    • Showing the toolbar in this case would make it very difficult to use the note editor. It may make sense to instead allow toggling the toolbar, note title input, and/or action bar on small screens. This would allow all of these controls to be accessed without also hiding most of the editor.

1.4.11. Non-text contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

  • User Interface Components
    Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
  • Graphical Objects
    Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

The below are based on the default light mode theme.

1.4.12. Text spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.
  • [🟡] [🔎] I don't think Android supports changing these by default. However, this should be double-checked.
    • [🔎] This document doesn't focus on the web app, but it may make sense to check this for the web app as well.

1.4.13. Content hover on focus (AA)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

  • Dismissible
    A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
  • Hoverable
    If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
  • Persistent
    The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

  • [🟡] (🖋️) Drawing tool: Allow hovering over toolbar hint text ("hoverable").
  • [🟡] (🖋️) Drawing tool: Make hint text satisfy persistent when navigating with the keyboard (unless dismissed with "esc").

Note: Tooltips on mobile are triggered by long-press and currently are not triggered by the keyboard. When this changes to satisfy 2.1.1, it should be ensured that the new shortcuts satisfy this SC.

2.1. Keyboard accessible

Make all functionality available from a keyboard.

  • [🔎] Check whether keyboard accessibility while a screen reader is enabled is sufficient. React Native has at least one issue that may make implementing full keyboard accessibility difficult. Additionally, it's unclear whether React Native exposes keyboard focus events on Android (may be needed for tooltip keyboard accessibility). Alternatively, we could focus on making the web version of the mobile app keyboard accessible.
    • For now, the keyboard accessibility sections focus on screen reader keyboard accessibility, which works differently from standard keyboard accessibility.

2.1.1. Keyboard (A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Physical keyboard issues:

  • [🔎] Should the keyboard show tooltips? (Is it possible to detect keyboard focus for this in React Native?)
  • [🔎] Do we need to handle the case where the user is trying to use a keyboard without a screen reader (in the Android version of the app)?
  • [❗] The "Actions" menu for each note cannot be used with a keyboard.
    • It can, however, be used with a screenreader, just not with a physical keyboard (when navigating with tab).
  • [❗] Android: Fix keyboard focus can get stuck between text inputs (upstream issue, should be resolved in RN >= 0.79).

Screen reader issues:

2.1.2. No keyboard trap (A)

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Note: 2.1.3 is level AAA

2.1.4. Character key shortcuts (A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off
    A mechanism is available to turn the shortcut off;
  • Remap
    A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
  • Active only on focus
    The keyboard shortcut for a user interface component is only active when that component has focus.
  • [❗] (🖋️) Drawing tool: Allow disabling single-character shortcuts (the w/a/s/d/q/e/r and h/j/k/l shortcuts for scrolling the viewport).
    • "Active only on focus" probably doesn't apply here because the tool takes up a full screen of the app.

2.2. Provide users enough time to read and use content

2.2.1. Timing Adjustable (A)

For each time limit that is set by the content, at least one of the following is true:

  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • 20 Hour Exception: The time limit is longer than 20 hours.

2.2.2. Pause, stop, hide (A)

For moving, blinking, scrolling, or auto-updating information, all of the following are true:

Moving, blinking, scrolling:

  • For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
    Auto-updating:
  • For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
  • [❗] As on desktop, the sync status notification auto-updates.
    • It currently isn't possible to hide this notification while browsing the notebook list (and thus it's "presented in parallel with other content").

2.2.3 - 2.2.6

SC 2.2.3-2.2.6 are all level AAA.

2.3. Seizures and physical reactions

2.3.1. Three flashes or below threshold (A)

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Note

A flash is defined as

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range

I have not observed Joplin to flash frequently in a short period of time.

Note: SC 2.3.2-2.3.3 are level AAA and thus omitted.

2.4. Navigable

2.4.1. Bypass blocks (A)

A mechanism is available to bypass blocks of content that are repeated on multiple web pages.

  • [❗] [🔎] The screen header component is repeated on multiple pages. Check that:
    • If, when navigating to a screen, focus is placed before the screen header, it's easy to tab to the main content.
    • OR: The screen header content doesn't count as "repeated" (since the header is different on different pages).

2.4.2. Page titled (A)

Web pages have titles that describe topic or purpose.

The SC includes the following note:

In cases such as Single Page Applications (SPAs), where various distinct pages/views are all nominally served from the same URI and the content of the page is changed dynamically, the title of the page should also be changed dynamically to reflect the content or topic of the current view.

  • [❗] [🔎] What is the equivalent for a page title in Android? Can we change it dynamically (should we?).

Also, on web:

  • Dynamically change the title of the page to match the current note and/or screen.

2.4.3. Focus order (A)

If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Joplin on mobile does not (as far as I'm aware) override focus order. However, this SC also discusses modal dialogs in its description. As such, (by F85)

2.4.4. Link purpose (in context) (A)

The purpose of each link can be determined from the link text alone or from the link text together with its programatically-determined context, except where the purpose of the link would be ambiguous to users in general.

The WCAG 2.2 defines "link purpose" as the "nature of the result obtained by activating a hyperlink". The mobile app uses few true hyperlinks. However, SC 2.4.6. seems to cover this case.

App controls/state: The hyperlinks in "more information" do currently describe their target in the content of the link (e.g. "Make a donation" with role "link").

Welcome notes: The welcome notes include a link with just the text "link", but it's included within a descriptive paragraph.

2.4.5. Multiple ways (AA)

More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process.

Note: The WCAG 2.2 spec defines "web page" as "a non-embedded resource obtained from a single URI using HTTP plus any other resources that reused in the rendering or intended to be rendered together with it by a user agent." As such, this doesn't seem to apply to Joplin mobile.

If this does apply to Joplin mobile,

  • Settings: Joplin mobile's settings support accessing settings via search and through the sidebar tabs.
  • Notes: Notes can be accessed through search or by accessing their parent notebooks.

2.4.6. Headings and labels (AA)

Headings and labels describe topic or purpose.

Note: SC 1.3.1/4.1.2 are similar to this success criterion, but is about whether labels are present or not (rather than their content).

2.4.7. Focus visible (AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

  • [🟡] Android: There are a large number of invisible (screen reader and visually hidden) components that do get focus when using a hardware keyboard. For example,
    • The sidebar is marked as inert and hidden for accessibility, but still gets keyboard focus.
    • The same is true for the invisible tooltip placeholders between buttons in the Markdown editor toolbar.

2.4.9-2.4.10 (AAA)

Skipped: SC 2.4.9-2.4.10 are level AAA.

2.4.11. Focus not obscured (minimum) (AA)

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

2.4.12-2.4.13 (AAA)

Skipped: SC 2.4.12-2.4.13 are level AAA.

2.5. Input modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

2.5.1. Pointer gestures (A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Note

Definition:

A path-based gesture involves an interaction where not just the endpoints matter, but how the pointer moves between these points.

  • Drawing: Rectangles and lines depend only on the start/end points (so are not a "path-based gesture"). Zooming is possible both with pinch-zoom and buttons in the "hand" tool menu (also with keyshortcuts).

2.5.2. Pointer cancellation (A)

For functionality that can be operated using a single pointer, at least one of the following is true:

  • No Down-Event: The down-event of the pointer is not used to execute any part of the function;
  • Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
  • Up Reversal: The up-event reverses any outcome of the preceding down-event;
  • Essential: Completing the function on the down-event is essential.
  • Drawing: Most actions can be undone with the "undo" button. For selection, touching the screen with a second finger converts the "select" action to a "zoom" action, which should satisfy "Abort or Undo". However, this requires a second pointer.
    • [❗] (🖋️) Add a way to restore the selection to whatever it was previously, without requiring a second pointer. I'm not sure what the UI for this will look like.
      • Perhaps returning the pointer to its starting point should cancel changing the selection? I don't think this makes sense for lasso selection, though...
    • [❗] [🔎] (🖋️) Add a way to restore the viewport to its previous location. The current logic of returning the pointer to its original location may be sufficient here.
  • Dialogs:
    • [❗] (🖋️) Touching outside, then dragging inside a dialog causes the dialog to be dismissed. (Tested on iOS).

2.5.3. Label in name (A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

This doesn't seem to apply to symbolic text characters (e.g. the "bold" button in the toolbar).

2.5.4. Motion actuation (A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

Note: Includes an "essential" exception.

  • Camera: Essential

2.5.5 - 2.5.6

These sections are level AAA and skipped.

2.5.7. Dragging movements (AA)

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

  • [🟡] Horizontal scrolling on the toolbar -- add buttons to scroll left/right.
    • This might not be necessary — what counts as "determined by the user agent" in this case? See discussion.
    • The "understanding" page does include "This criterion does not apply to scrolling enabled by the user-agent."
  • [🟡] (🖋️) Drawing: Add a way to create shapes with only a single pointer.
    • Check how other apps do this. One option might be to make a "click" gesture add shapes when using a shape tool. However, it might be difficult to determine whether a user intends to click or draw.

2.5.8. Target size (minimum)

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

  • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
  • Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
  • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
  • User agent control: The size of the target is determined by the user agent and is not modified by the author;
  • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
  • The accessibility scanner marks a few touch targets (that seem to be actual touch targets) as smaller than 48x48 px, but these are all above 24x24 px.

3.1. Readable

3.1.1. Language of Page (A)

The default human language of each web page can be programmatically determined.

3.1.2. Language of parts (AA)

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

  • [🟡] [🔎] Is it possible to apply this to fallback text for partial app localisations?
    • For example, if a string isn't translated by the community, it's currently loaded as English text.

3.1.3 - 3.1.6 (AAA)

Skipped.

3.2. Predictable

3.2.1. On focus (A)

When any user interface component receives focus, it does not initiate a change of context.

Note

The WCAG defines "changes of context" to be:

major changes that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously

It includes "focus" and "content that changes the meaning of the web page" as examples.

Screen reader/keyboard focus does not seem to cause changes in context in the mobile app.

3.2.2. On Input (A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

  • [❗] [🔎] To check: Does toggling a task in the note list cause a change in context (e.g. focus change) when the list re-sorts?
    • Not for short lists, but maybe for long lists.

3.2.3. Consistent Navigation (AA)

Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Joplin uses the same header component for different screens and does not seem to re-order the header buttons on different screens. As such, this should be met.

3.2.3. Consistent Identification (AA)

Components that have the same functionality within a set of web pages are identified consistently.

  • [🟡] [🔎] Check: Do the checkboxes in the note list have similar labels to those shown when viewing a note?
  • [🟡] [🔎] Check: Are the items in the note actions menu assigned labels consistent with those in the Markdown toolbar?

3.2.5. Change on request (AAA)

Skipped (level AAA).

3.2.6. Consistent help (A)

If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

Current places with contact/help information:

  • Settings:
    • This is a single screen, in which information should always be in the same place (perhaps unless showing as a search result in settings).
  • Drawing:
    • Help buttons, if available, are always the button just after the "toggle menu" button.
  • Plugins:
    • [🔎] Installed plugins and not-installed plugins have different ways of accessing the "about" page for the plugin in search results. Check whether the success criterion applies to this. If so, change the plugin search results such that they have a consistent layout. (I don't think it applies due to the "repeated on multiple web pages within a set of web pages" statement).

3.3. Input assistance

3.3.1. Error identification (A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

3.3.2. Labels or instructions (A)

Labels or instructions are provided when content requires user input.

This success criterion may be met. Cases that need to be looked into include:

  • The checkbox next to a note title. This may be considered labelled by the note title.

Note

This success criterion is different from SC 1.3.1. From the "understanding" document:

This success criterion does not require that labels or instructions be correctly marked up, identified, or associated with their respective controls - this aspect is covered separately by 1.3.1: Info and Relationships. It is possible for content to pass this success criterion (providing relevant labels and instructions) while failing Success Criterion 1.3.1 (if the labels or instructions aren't correctly marked up, identified, or associated).

3.3.3. Error suggestion (AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

  • Encryption config screen:
    • Enabling encryption with non-matching passwords: A "Passwords do not match" dialog box is shown when clicking "enable" if the passwords do not match. Similarly, the dialog box states "Password cannot be empty" if an empty password is provided.
  • Number settings inputs — suggestions are shown below the input (e.g. "Keep note history for cannot be less than 1").
  • Sync setup — "check synchronization configuration button" is available for certain sync targets.

3.3.4. Error prevention (AA)

For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

  • Reversible: Submissions are reversible.
  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Joplin can "delete user-controllable data in data storage systems" (e.g. delete notes). At present:

  • Items are deleted to the trash folder.
  • A confirmation dialog is shown when a user clicks "permanently delete" from the trash or long-presses on "Trash", then selects "empty trash".
  • [🔎] Are Joplin's current checks related to data on the sync target sufficient?

3.3.5-3.3.6 (AAA)

SC 3.3.5-3.3.6 are level AAA and thus omitted from this document.

3.3.7. Redundant entry (A)

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

  • auto-populated, or
  • available for the user to select.

Except when:

  • re-entering the information is essential,
  • the information is required to ensure the security of the content, or
  • previously entered information is no longer valid.
  • [❗] Pre-populate search in the Markdown editor with the global search query.

3.3.8 Accessible Authentication (AA)

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

4.1. Compatible

Note: SC 4.1.1 is marked as (Obsolete and removed).

4.1.2. Name, role, value (A)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

4.1.3. Status messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

  • [❗] [🔎] The statement specifies "content implemented using markup languages", so may not apply to Joplin mobile. If it does, check the following:
    • Sync error message.
    • Error messages for number inputs in settings.

Notes on accessibility testing

Screen reader testing

For items related to screen reader accessibility, I'm testing primarily with the following screen readers:

  • Linux: Orca
  • Windows: NVDA
  • MacOS: VoiceOver
  • iOS: VoiceOver
    • Note: Enabling VoiceOver globally in MacOS also enables it for the iOS simulator
  • Android: TalkBack

Mobile: Finding contrast issues

On Android, the Accessibility Scanner may also be helpful in identifying and fixing certain accessibility issues (e.g. contrast, unlabeled content).
@personalizedrefrigerator personalizedrefrigerator added bug It's a bug mobile All mobile platforms accessibility Related to accessibility labels Jan 16, 2025
This was referenced Jan 16, 2025
Open
Merged
Merged
Merged
Closed
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
This was referenced Jan 31, 2025
Closed
Merged
@mrjo118
Copy link
Contributor

mrjo118 commented Mar 27, 2025 •
edited
Loading

Uncategorized/external keyboard: TextInput blocks focus (facebook/react-native#45801)

Regarding this point, I gave it a go adding the https://www.npmjs.com/package/react-native-external-keyboard dependency and replacing the usage of the TextInput component to be a KeyboardExtendedInput component. Out of the box this change alone does fix the issue on Android (I have not tested on IOS) so that you can tab or use the arrow keys on an external keyboard to switch between all the settings options without getting blocked by the TextInput - I also tested it with Talkback and it correctly reads the value. Note that the styling of the TextInput does require a bit of tinkering though to match the existing styling for a TextInput, as by default the width of the input contracts to the size of the input value instead of being fixed. Also note that when the KeyboardExtendedInput is in focus via the tab or arrows keys, you have to press the space bar first, in order to allow changing the value. If you press the field with your finger or mouse click though, it will immediately be in edit mode and you can start typing the value.

Also there looks to be an additional accessibility issue when using an external keyboard. You can open up a dropdown field by pressing enter when it is in focus, however it is not possible to change the selected value in the dropdown using an external keyboard, as far as I can tell, as the dropdown items are no selectable with the arrow keys.
EDIT: Actually, this is not an issue. You can select a drop down item if you get the dropdown in focus, press enter, and then press tab, which then allows you to select an option using the arrow keys. Though sometimes you have to press tab twice in order to get the dropdown items to be in focus

FYI this is just for informational purposes. I don't think I will be investing further effort to implement these changes for a PR.

@personalizedrefrigerator
Copy link
Collaborator Author

Regarding this point, I gave it a go adding the https://www.npmjs.com/package/react-native-external-keyboard dependency and replacing the usage of the TextInput component to be a KeyboardExtendedInput component.

Thank you for checking!

@personalizedrefrigerator
Copy link
Collaborator Author

personalizedrefrigerator commented Apr 15, 2025 •
edited
Loading

Uncategorized/external keyboard: TextInput blocks focus (facebook/react-native#45801)

It might be fixed upstream! From an upstream commit message:

This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a TextInput. This is because Android will call requestFocus from here when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus TextInputs since they go through ExploreByTouchHelper methods which we override to call the proper requestFocusInternal() method.

Based on this, upgrading to React Native >= 0.79 may fix the issue.

This was referenced Apr 15, 2025
Merged
Merged
Merged
Merged
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
accessibility Related to accessibility bug It's a bug mobile All mobile platforms
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mrjo118 @personalizedrefrigerator