Change Details

Two remaining accessibility issues broken out from T404743 we need design check on before proceeding: [ ] app label is currently "Image carousel"; should this be "Image browsing" or something else? [ ] missing next/previous buttons: ARIA recommendations for an image carousel widget are that there must be 'next' and 'previous' buttons, but we don't have any. - this makes it relatively hard to "browse" through the image set in detail view, as scrolling by keyboard or accessibility gesture is slow and imprecise compared to flinging the screen on an iPhone in visual mode - adding them may require making visible items, hence check with design Per standup discussion we probably don't need to finish this before the experiment deployment, but should definitely resolve it if we move the feature forward after testing.

Ensure the image carousel component meets accessibility standards, including screen reader support, keyboard navigation, and compliance with ARIA authoring practices for carousel widgets. The [[ https://www.w3.org/WAI/ARIA/apg/patterns/ | Aria Pattern Guide ]] has an example gallery/carousel example that should be referenced here: https://www.w3.org/WAI/ARIA/apg/patterns/carousel/ === Context During the prototype phase, an accessibility audit (T404743) identified two unresolved issues specific to the carousel. As we scale this feature to production (T410786), these need to be addressed along with any other accessibility requirements for the new carousel implementation in its production codebase. === Known issues from prototype audit - **Widget label**: The prototype used "Image carousel" as the ARIA label. We should confirm the appropriate label for the production feature. - **Next/previous navigation**: ARIA authoring practices for carousel widgets recommend dedicated next/previous buttons. The prototype lacked these, making it difficult to browse images via keyboard or assistive technology — swiping is not available to all users. === Additional considerations - Ensure carousel images have appropriate alt text - Keyboard focusability and navigation within the carousel - Sufficient touch target sizes for interactive elements - Behavior when carousel is empty or has only a few images === Open questions - Does the carousel need visible next/prev buttons, or can they be screen-reader-only? (Likely needs design input from @JScherer-WMF) - See T408831 for a related VoiceOver issue with image markup that may also apply to carousel thumbnails === Related - Prototype accessibility audit: T404743 - Detail view accessibility will be tracked separately

Two remaining accessibility issues broken out from T404743 we need design check on before proceeding:Ensure the image carousel component meets accessibility standards, including screen reader support, keyboard navigation, and compliance with ARIA authoring practices for carousel widgets. The [[ https://www.w3.org/WAI/ARIA/apg/patterns/ | Aria Pattern Guide ]] has an example gallery/carousel example that should be referenced here: https://www.w3.org/WAI/ARIA/apg/patterns/carousel/ [ ] app label is currently "Image carousel";=== Context During the prototype phase, an accessibility audit (T404743) identified two unresolved issues specific to the carousel. As we scale this feature to production (T410786), these need to be addressed along with any other accessibility requirements for the new carousel implementation in its production codebase. === Known issues from prototype audit - **Widget label**: The prototype used "Image carousel" as the ARIA label. We should confirm the appropriate label for the production feature. - **Next/previous navigation**: ARIA authoring practices for carousel widgets recommend dedicated next/previous buttons. The prototype lacked these, should this be "Image browsing" or something else?making it difficult to browse images via keyboard or assistive technology — swiping is not available to all users. === Additional considerations - Ensure carousel images have appropriate alt text [ ] missing next/previous buttons: ARIA recommendations for an image carousel widget are that there must be 'next' and 'previous' buttons, but we don't have any.- Keyboard focusability and navigation within the carousel - this makes it relatively hard to "browse" through the image set in detail view, as scrolling by keyboard or accessibility gesture is slow and imprecise compared to flinging the screen on an iPhone in visual mode- Sufficient touch target sizes for interactive elements - adding them may require making visible items, hence check with design- Behavior when carousel is empty or has only a few images Per standup discussion we probably don't need to finish this before=== Open questions - Does the carousel need visible next/prev buttons, or can the experiment deployment,y be screen-reader-only? but should definitely resolve it if we move the feature forward after testing.(Likely needs design input from @JScherer-WMF) - See T408831 for a related VoiceOver issue with image markup that may also apply to carousel thumbnails === Related - Prototype accessibility audit: T404743 - Detail view accessibility will be tracked separately