Notebook cell actions are not announced to screenreader.

[tonyfast]

User does not really know when cell was run, stopped, moved, duplicated, etc. successfully or what the cell is currently outputting automatically without manually doing it as it's popping out (which they won't be able to see to know to follow alone.

Issue Area # 4

• Expectation: User is informed when content changes dynamically away from the focus (WCAG Criteria 3.2.2 (A), 4.1.2 (A), & 4.1.3 (AA))
• Observed: On notebook page when preforming all code cell actions (runs, stops, moves, duplications, etc.) it's not mentioning this to screenreaders. On move it should send a screenreader only alert saying ex. "Code cell number 4 has swapped with code cell 3 successfully" or at minimum "cell move successful". Whenever a cell is run, I expect it to say ex. "Running cell 3", say the output as it's happening, example "Packages already installed: pandas", etc. then will read either "Cell 3 finished successfully" or "Cell 3 failed. Error: {insert error}.

[tonyfast]

copied from the milestone.

Notebook cell actions are not announced to screenreader. User does not really know when cell was run, stopped, moved, duplicated, etc. successfully or what the cell is currently outputting automatically without manually doing it as it's popping out (which they won't be able to see to know to follow alone.

This one is hard because it is so big. And important. I don't think we have an ideal experience for this even for our sighted users. I want to call it a blocker but I do not know how we would solve it.

Not sure if this is a path you want to go but I always add this kind of capability by doing the following.

1. Create <div id="screenreaderAlerts" class="sr-only"></div> and slap at the bottom of your page somewhere (or perhaps at bottom of the notebook pages if we want to keep this small for now).
2. Insert following function in JS where the other JS files inherit it and can thus use it.

/* ===== Make Screenreader-Only Alert ===== */
function makeScreenreaderAlert(element_id, on_message, off_message){
  let element = '#' + element_id;
  if ($(element).length){
    $(element).text(message);
  }
  else {
    $('#screenreaderAlerts').apend('<div id="' + element_id + '" role="alert">' + message + '</div>');
  }
}

3. After what JS or whatever controlling the moving, running, deleting, etc. of the notebook cells, just follow it up with a:

makeScreenreaderAlert('notebookActionAlert', 'Cell has finished running.');

The purpose of the element_id part of it is so you can override it with other actions of the same type and users can re-read alerts as they wish and it doesn't take away from the visual-user experience. Example of the former is if you want to fire one on cell run start and cell run finish, if it's a 20 second cell run, it could alert them that "Cell has started running" and then would read that "Cell has finished running". If the cell only takes 0.5 seconds to run, it may only read "Cell-" of that first message before getting interrupted/replaced and reading "Cell has finished running" in full. Anyway that's just how I do it for my other apps, you do you though.

[tonyfast]

to clarify, these announcements are non visual alert or status announcements through the aria-live standards. they don't really relate the window.notifications api or toast alerts.

from the aria live mdn docs:

status

A status bar or area of the screen that provides an updated status of some kind. Screen reader users have a special command to read the current status.

alert

Error or warning message that flashes on the screen.

it seems that cells completing would make sense as status roles. if execution fails, and that can be detected, then the status should be an alert identifying the failure as @manfromjupyter suggests.

the aria live features shouldn't visually impact the the notebook. it seems that announcements could go in either the .jp-OutputArea or in the .jp-CellFooter. if we can visually hide output elements, that are implicit live regions, they would be the ideal place for this feature.

fixing this likely requires a single pull request that:

• identifies a location for screen reader notifications
• adds messages for the basic lifecycle of running a cell.

in the future, we might find sounds are appropriate for less important messages like adding a new cell, rendering some markdown.