new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Shopify Polaris · all subjects

accessibility

114 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Accessibility applies to mobile as well

All accessibility requirements apply to mobile as well. iOS and macOS have VoiceOver built in, and there are many apps that create new possibilities for users with disabilities.

Design accessibility as well as technical accessibility

Accessibility should be thought of as both a design and usability issue, not just a technical issue. Design is improved when people with disabilities participate in the design process.

TrapFocus focus management behavior

TrapFocus focuses its first focusable child on mount and resets focus to the first focusable child whenever a blur event would move focus outside the trap container.

Video captions must be supported

Captions must be supported for both prerecorded and live video content.

Polaris WCAG conformance target

Polaris components must meet Level A and Level AA success criteria of the Web Content Accessibility Guidelines (WCAG 2.1).

Automated accessibility testing tool

Pa11y is recommended as an automated testing tool to run locally before submitting pull requests for accessibility compliance.

When to test accessibility for content changes

If you have added content, test the Structure section and the Visuals section.

When to test accessibility for interactive elements

If you have added interactive elements, test the Keyboard actions section.

When to test accessibility for dynamic content

If you have added dynamic content or controls, test the Dynamic content section.

When to test accessibility for mobile web

If you are developing for mobile web, test the Touch and motion inputs section and the Mobile layout section.

When to test accessibility for media

If you have added images, video, or audio, test the Media support section.

Content must be in HTML

Content that users should access must be marked up in HTML, not hidden from assistive technologies.

Hidden content must not be accessible

Content that should not be available to users must not have `hidden`, `aria-hidden="true"`, `visibility: hidden`, or `display: none` applied in a way that makes it accessible.

Semantic HTML elements must be used appropriately

Semantic HTML elements such as `<header>`, `<nav>`, and others must be used when appropriate to mark up content.

Content must be in logical order

Content must be in a logical order to understand and use the feature.

Links versus buttons usage

Links must be used for navigation and buttons must be used to submit data.

HTML tables must mark up tabular data

HTML tables must be used to mark up tabular data, not for layout purposes.

Headings must be in logical order

Headings must be in a logical order for the page section using appropriate heading levels (`<h1>`, `<h2>`, etc.).

Color alone must not convey information

Color alone must not be used to distinguish features or convey information. Features must use text or icons in addition to color to convey meaning.

Components must be visible in Windows High Contrast mode

User interface components and states that rely on background color or border color must have a visual indicator visible to Windows High Contrast mode users.

Text color contrast requirement for informative content

Informative content must have a color contrast of 4.5:1 against backgrounds, including gradients and images. Disabled control text is exempt.

Text must be resizable to 200%

Text must be able to be resized by 200% in the browser without loss of functionality.

Interface component color contrast requirement

Interface components (like form field borders) and informative icons must have a color contrast of 3:1 against backgrounds, including gradients and images. Logos, decorative images, and disabled controls are exempt.

Interactive features must be keyboard accessible

Interactive features must be able to get focus and be used with the keyboard. Native interactive features must get standard keyboard focus and inputs, with and without a screen reader running.

Custom ARIA features must follow ARIA authoring guidelines

Custom, ARIA-based features must be usable with the keystrokes recommended in the ARIA authoring guidelines or those defined in the Polaris style guide, with or without a screen reader running.

Keyboard focus must not be trapped

Keyboard focus must not become trapped with no way to exit or close features, with or without a screen reader running.

Modal focus management requirement

Features like modals that capture focus on purpose must be dismissable with the keyboard (ideally with the Escape key as well as a visible, labeled, keyboard-accessible control) and must manage focus to a logical place when they close.

Embedded content must not trap focus

Embedded content like iframes must not trap keyboard focus.

Character key shortcuts must be remappable

Custom keyboard shortcuts using single letter keys must be able to be turned off or remapped, and must only be active when the relevant feature has focus.

Keyboard focus must follow logical reading order

Keyboard focus must move in a logical path that follows the reading order. Focus must not go off-screen to content that is not meant to be accessed, and must not be set with positive `tabindex` values.

Keyboard focus navigation directions

Focus must be able to move forward using Tab and backwards using Shift + Tab.

Focus indicator must be visible

When an element has keyboard focus, the focus indicator must be visible.

Focus must not cause change of context

Moving focus to an element must not cause a change of context. Inline content must not display or hide, navigation must not happen, and control settings must not change.

Hover/focus content must persist

Features that are shown on hover/focus must be persistent until hover/focus is removed or otherwise dismissed by the user.

Hover content must be accessible when hovering over feature

Features that are shown on hover must not be hidden if the mouse pointer is moved to the feature itself.

Animated content must be pausable

Features that automatically update or animate must be able to be paused, stopped, or hidden by users.

Looping video must have pause control

Looping or autoplaying videos must have an accessible button to pause or stop the video.

SVGs must have separate text equivalents

SVGs must rely on separate text equivalents, since they are not consistently conveyed by assistive technology.

Animation must support prefers-reduced-motion

The `prefers-reduced-motion` query must be supported for features that use CSS for animations.

Control activation must not cause unexpected context change

Activating a control must not cause a change of context unless users are warned beforehand.

Links opening new windows must be indicated

Links that open new windows must be conveyed with an icon that has a text alternative.

Controls must convey accessible names, roles, states, and properties

Accessible names, roles, states, and properties must be conveyed clearly to assistive technologies. Controls that have different states, properties, or values must convey them programmatically.

Complex ARIA features must follow ARIA recommendations

Complex features that rely on ARIA must be built according to the ARIA 1.1 recommendation and the ARIA 1.1 authoring practices, or guidelines provided in the Polaris style guide.

Complex features must be tested with assistive technologies

Complex features must be tested with assistive technologies. Support for the following should be considered: VoiceOver with Safari on macOS and iOS, NVDA with Firefox on Windows 10, and TalkBack with Chrome on Android.

Multi-point gestures should be avoided

Multi-point and path-based gestures should be avoided unless they are essential to the feature. Native gestures should be used following specifications, and custom gestures should be kept simple.

Touch control cancellation requirement

When tapping a control, users should be able to hold, press, and drag their finger away without triggering the interaction.

Motion-activated features must have alternative interfaces

Features that are activated through motion must also be usable with an interface, and must be able to be turned off.

Content must be accessible in portrait and landscape

Content must be accessible in both portrait and landscape orientations, unless the feature is not valid in more than one orientation.

Informative images must have alt text

Informative images must have an `alt` value supplied.

Content must reflow at smaller breakpoints

Content must be resizable to smaller breakpoints without triggering horizontal scrolling. Content that cannot be resized without losing context, like tables, large images, or similar features, are exempt.

Decorative images must have empty alt text

Decorative images must have `alt=""`.

Icons conveying control purpose must have text alternative

In cases where an icon is used to convey the purpose of a control, the icon must have a text equivalent that describes its purpose.

Video features must have text alternatives

Video features must support text alternatives like an audio track or audio description.

Audio features must have text alternatives

Audio features must support a text alternative.

Give your agent this brain