You wrote: Is there any expectation from Apple that developers / app owners audit or regularly review their own claims of accessibility over time as features and enhancements occur? Quoting from Planning for your Responses You’re responsible for keeping your responses accurate and up-to-date. If your practices change, please update your responses. Also most eval criteria pages include something similar to this line in the VoiceOver criteria: Even after you’re able to indicate support for VoiceOver in the common tasks of your app, there are likely further improvements you’ll be able to make to the accessibility of your app. Re-evaluate your app's support for VoiceOver every time you update your app. Set a goal to make your app more accessible to more people in every release.

Quoting from the Additional Guidance section: If bugs are significant enough to change your answer according to the Accessibility Nutrition Labels evaluation criteria, then don’t indicate support for the accessibility feature. To avoid misleading users, you shouldn’t enter answers that aren’t aligned with the evaluation criteria. Ultimately each app owner is responsible for determining what their core, common tasks are, and whether their app is in line with the criteria for each label. Whether a particular bug prevents the user from completing a common task is subjective depending on the skill of the user, but some common sense applications apply. For example, if a missing label on a Delete button causes a permanent, destructive action, it's obviously more serious than a missing label on a non-desctructive menu. Likewise, a single contrast failure at a 4.49:1 luminosity ratio (just below the minimum recommended threshold) will not be as impactful to the user as a more extreme, or more pervasive, problem in the app. Also from the end of the Tips section: You may consider exceptions to the recommendations here if users with disabilities would find them reasonable. For example, you might hide a button from VoiceOver in one view if it duplicates functionality that’s already available and discoverable elsewhere. If you aren't sure about whether the example missing label or contrast issue prevents a user from successfully completing a task, consider hiring users with various disabilities either as full-time employees, or as contracted part-time participants in your regular TestFlight evaluation. The closing guidance on each criteria page may be helpful with your evaluation, too: Even after you’re able to indicate support for [accessibility feature] in the common tasks of your app, there are likely further improvements you’ll be able to make to the accessibility of your app. Re-evaluate your app's support for [accessibility feature] every time you update your app. Set a goal to make your app more accessible to more people in every release. I'm hopeful it's clear that acknowledges 100% perfection is not achievable, and therefore not expected. However, "if bugs are significant enough to change your answer according to the Accessibility Nutrition Labels evaluation criteria, then don’t indicate support for the accessibility feature." Good luck!

This should be resolved as of iOS 17.6. The latest update was August 7th. Please include OS version. Thanks!

You can also hold the lock button, and tell Siri to "Turn off VoiceOver."

If you want background images to avoid the invert, you can use the CSS media feature: @media (inverted-colors) { .mySelector { filter: invert(100%); } } The selected element will still be inverted screen pixels, but applying the invert filter means it's effectively "double-inverted" so it looks normal, as if it was never inverted.

I can't speak specifically to the Bootstrap component you're using, but in general there are API differences between iOS Native, and the Web Platform. It's not always 1-for-1. For example, the Web Platform design principles specifically forbid accessibility-specific API (https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech), so you can't intercept an accessibilityScroll event directly. That said, you can intercept certain mainstream events (focus, scroll, etc) that occur downstream. If you’re trying to get the “as-close-to-iOS-Native-as-possible” experience (e.g. using the 3-finger VO page-scroll gestures), you might try a scroll-snapped backing div that catches the scroll event (either directly or with document.body delegation), and shows/focuses the now-current carousel panel. This might require some finagling and you should test it thoroughly with iOS VoiceOver, Android TalkBack, and as many desktop browser and screen reader combinations as you can test. An easier way is to make each panel always accessible and update your carousel controller when you receive any focus event on or in that panel. If you want VO heading navigation to work well, don't forget to add tabindex="-1" on the panel headings too, so that you can have an event listener for that focus, and update your carousel view controller.

Seems like a bug. Will you file it at bugs.webkit.org? Thanks for including the CodePen.

Please include the version number of the OS and browsers you are testing. Thanks.

Check out CSS MQ Level 5: https://drafts.csswg.org/mediaqueries-5/ The prefers-reduced-motion and prefers-reduced-transparency features are 1-to-1 correlations with the native API features on Apple devices. prefers-contrast has gone through iterations, so YMMV with regard to support, but the current syntax of @media (prefers-contrast: more) is intended to match the "Increase Contrast" feature on Apple devices, as well as similar higher contrast features on Windows and Android. Some of the values being discussed in that feature are Windows-specific or otherwise not relevant to iOS or macOS. There is currently no Web API feature equivalent to the Button Shapes setting. You can also use these media features with the window.matchMedia interface.