The problem is with the Canvas editor. It is super accessible but can be confusing for a screen reader user -- I am one and have used JAWS NVDA and Narrator to take about thirty Canvas courses as a student. I am now creating my first course.
It's a little complicated to explain this, but I'll try. When the screen reader user first explores a page that includes the editor, they are in a mode called "browse" or virtual cursor mode. This means they use the arrow keys to move through the content -- left, down up right etc. The web page is shown to them exactly like a word processor document.
To actually type something, the user must toggle on a mode called "forms mode" or "focus mode". Screen readers have different names for this, but basically there is one mode for reading and exploring the page, another for actually typing and interacting.
In most cases, this works just fine. But with Canvas, when you enter that forms/focus mode, you end up on the toolbar and not in the editor. So if you start pressing keys, you end up doing toolbar things rather than edit things -- enter doesn't create a new paragraph, it activates a toolbar item.
So you have to navigate past the toolbar to the actual edit field and the way to navigate is different depending on which mode you are in. If you are in browse/virtual cursor mode the arrow keys will move through the page. If you are in focus/forms mode, and you are on the toolbar, for example on the background color selection, pressing down arrow takes you through a list of colors.
Once you get to the edit field, the screen reader may or may not protest and throw you back in to virtual cursor/browse mode, because it doesn't realize that you are still in an element where you can interact. This is a bigger issue with older versions of the screen readers.
If you stay in the virtual cursor/browse mode where you can only read and not interact, you can move past the toolbar to focus on the edit box. But then, if you try to turn on the forms/browse mode then, the screen reader sometimes refuses to activate it because you are in the middle of the editor, not at the beginning, so it thinks you can't interact and won't let you.
The secret is to activate some toolbar item like align left by arrowing to it and pressing enter. Then press escape to actually enter the editor to type.
So the steps are these: navigate to the toolbar. Enter your focus or forms mode. Arrow or tab to a toolbar item that won't cause any damage and press enter. Press Escape. You are now in the editor.
If the toolbar didn't come first in the document object model this wouldn't be a problem. But because it comes first, it's confusing for a screen reader user who must actually navigate through its huge forest to get to where they need to edit.
I've simplified the explanation: there's also something called "application mode" which screen readers seem to turn on when they feel like it or encounter an aria tag that tells them to do so. Its purpose is to tell the screen reader that this is now a web application and all keystrokes need to be passed through to the application. Application mode gets turned on in the editor but not always depending on where the user has navigated to. It would be good if some advanced-level screen reader user in conjunction with a Canvas developer could test this together to figure out if it's a Canvas or a screen reader bug. But you can suddenly be in application mode, issue keystrokes intended for the screen reader and Canvas starts responding to them -- very confusing!
Hope this explains things a bit better.
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.