I don't think a framework can make a blanket statement about accessibility unless it's a negative one. Even if the framework does everything right, user error can completely break accessibility inadvertently. All such a statement does is give people a false sense of security that they ticked the "accessibility" checkbox, leaving people dependent on a screen reader, Braille device, with a motoric navigation difficulty, etc. completely stranded.
I have a habit of turning on NVDA, Android Talkback, etc. quite frequently to test when I'm working on a website, but even then, there are big differences between screen readers and a blanket statement of accessibility is completely worthless. People frequently tell me that something I tested on several Windows/Android devices doesn't work on Voiceover despite following the relevant standards. It's like browsers in the IE6 era, you need to explicitly test with as many as you can. And yes, it sucks.
Comments
I don't think a framework can make a blanket statement about accessibility unless it's a negative one. Even if the framework does everything right, user error can completely break accessibility inadvertently. All such a statement does is give people a false sense of security that they ticked the "accessibility" checkbox, leaving people dependent on a screen reader, Braille device, with a motoric navigation difficulty, etc. completely stranded.
I have a habit of turning on NVDA, Android Talkback, etc. quite frequently to test when I'm working on a website, but even then, there are big differences between screen readers and a blanket statement of accessibility is completely worthless. People frequently tell me that something I tested on several Windows/Android devices doesn't work on Voiceover despite following the relevant standards. It's like browsers in the IE6 era, you need to explicitly test with as many as you can. And yes, it sucks.