| 2 | | > As mentioned [https://wordpress.slack.com/archives/core/p1487193774008984 in the last dev meeting on Slack] this should be extensively tested with assistive technologies. We'll discuss during next accessibility team meeting and probably ask the a11y testers group to test the current patch or the Codepen. In the meanwhile, I've done some first testing with screen readers and, although it's a bit early to make any judgment, first impressions are not so great. Seems navigating through content in the editor is extremely hard and I'd say it's a regression compared to the native textarea. |
| 3 | | |
| 4 | | Andrea, what would be the gold standard in terms of a dedicated screen reader code editor? Is there one out there which does all of this and more really well? |
| 5 | | |
| 6 | | I'm asking as it seems it would be a much better experience for screen reader users to get the best screen reader code editor in the world rather than a bunch of patches on top of CodeMirror. Full cross compatibility (i.e. the final code created with both does not conflict) with the CodeMirror code editor for non-screen reader users would of course be essential. |
| | 2 | > Andrea, what would be the gold standard in terms of a dedicated screen reader code editor? Is there one out there which does all of this and more really well? |
| | 3 | @foliovision not that I'm aware of. We can do some research though. I think most of the issues are because `contenteditable` is still buggy and inconsistent across browsers. Add screen readers on top of that and you have an additional layer of buggy behaviours and inconsistencies. Even editors that have a complete different approach, for example [https://facebook.github.io/draft-js/ draft.js], use `contenteditable`. |