AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
> otherwise, I'm working on implementing a mode where CodeMirror does use > In the context of mobile support, where you can't get sane selection (In reply to Marijn Haverbeke from comment #12) Marijn, do you have any ideas how to keep the previous, current, and next lines always within the native textarea element? I can't remember if we could keep the textarea full until the start of input as opposed to running this timeout that cleared it. Additionally, when text is selected the textarea got filled with just the selected text (I think to enable clipboard access). I believe this could also be used to keep the entire content within the hidden textarea by setting a sufficiently high N, but the problem is that it has to be cleared out again for accepting input. I think I did have a version of the patch that kept N lines of context above and below the currently selected one. > main content area separately, so this isn't a total show stopper. However, while ugly, more experienced users could review the > previous, current and next lines is always exposed in the input area. Cursor movement and braille *might* work if the text for the > be extremely difficult (if not impossible) to make this properly accessible > If this is how things are going to stay (no contentEditable), it's going to I found that link just after I posted the comment. Maybe there is some hidden event or other notification to indicate that the selection has changed that I'm not aware of. My proposed solution could work if there were a way to signal to the screen readers that a selection change has happened, but I was unable to get it to detect the change unless if I waited to clear the textarea until after an arbitrary timeout. It may be best to come up with a reduced test case that simulates what CM is doing to make that easier. It would be good to have a conversation with NVDA and Marijn to come up with a plan for how to add accessibility support to CM in a clean way that would work across screen reader systems. > provided that it was implemented cleanly and works on more than a > longer necessary (and the context is stably present in the textarea), > resetInput and readInput, in such a way that the resetting is no > But I'd be open to an option that modifies the behavior of both > there's going to be more needed to have something that broadly works > and the uncertainty about other tools, gives me the feeling that > The thing about a random timeout to make the NVDA tool notice this, Here is what Marijn (the author of CM) said in a thread discussing the research from : Marco, could you please check if the situation has improved on the main demo page of, I'd be more than happy to update to the latest version of CM if it improves the accessibility situation. If there was some way to indicate to NVDA that a change has happened that would be good. If we wait to clear in a timeout it does notify. Clearing here will cause NVDA to not notify of the cursor movement. I'm not sure if the CM implementation is exactly the same as when I last looked, but basically what we need from NVDA is some way to notify a change has happened after running: I have a fix but it's too hacky to land in CM (it uses a timeout to allow NVDA time to see the changes). The tab button's behavior is overriden as you would expect with a code editor, which makes it hard to leave the field. Compare the following behavior with the normal textarea at the bottom of the page. Although you can generally tab into the editor without a mouse, leaving the editor is tricky and I've had to resort to mouse usage to do this. This is because the textarea is usually left empty, cleared out on regular intervalsĮntering / exiting the editor does not work. In this case it replaces the character with a - and marks cm.display.inaccurateSelection for cleanup later It fails when the selection is over 100 lines or 1000 characters. * Selection works some of the time, as it populates the textarea with the current selection. * Text based input works, as the input is being added directly into the hidden textarea I did some research about this last year and wrote about it here. So, text input in CodeMirror works, but accessibility support for cursor movement does not (see Bug 919711). > CodeMirror (as used by Scratchpad) is at lease basically accessible. > Let's move this to the proper component, then. > (In reply to Marco Zehe (:MarcoZ) from comment #2) (In reply to Joe Walker (overloaded - needinfo me or ping on irc) from comment #3)
0 Comments
Read More
Leave a Reply. |