Page 1 of 1

Screen reader accessibility of tags, review comments, and validation issues

Posted: Sat Sep 19, 2020 12:33 am
by david.badger
Hello, we're using Web Author Component 21.1.1 with Accessibility Optimization enabled.

Our 508 JAWS testing team is having a few issues related to keyboard navigation inside the Document view. Specifically, how is a visually impaired user utilizing a screen reader able to discern when the cursor is inside text that has an associated comment, and how can they use the keyboard to read, select that comment, and perform an action? The style in the editor for the background color for comments isn't labelled as such utilizing ARIA. Additionally, the tooltip that appears when the mouse hovers over one of these commented areas doesn't appear to be accessible via the keyboard. Can you recommend a keyboard only method for achieving this? The same thing goes for validation issues.

Element tag boundaries aren't ARIA labelled either, is the Ctrl+F2 shortcut to provide more information about the context element meant to be a substitution for this?

Thank you!

Re: Screen reader accessibility of tags, review comments, and validation issues

Posted: Mon Sep 21, 2020 6:56 pm
by andrei_popa
Hello,

The keyboard method for interacting with comments is to press Ctrl+F6 to switch to the review panel and then focus the review items list.
It will read the currently selected review item and you can use the keyboard to navigate through review items and perform actions.
The Enter or Space key will expand/collapse the currently selected view in the side panel.
For validation items you should press Ctrl+F6 and switch to the validation panel.

The hover tooltip offers a subset of actions available in the corresponding panel.
It is not keyboard accessible currently. I've added a feature request in our internal issue tracker for it. Perhaps we could show it on Ctrl+F3.
Ctrl+F2 is meant to provide more information about the current element.
Do you have any (other) shortcuts or good practices you have gotten used to from other applications?

We have tried to use semantic elements to mark different types of content the user may encounter.
For insert/delete changes we used ins/del and for comments markers we used the mark element.
However, it seems that the mark element is not read by screen readers by default, at least not yet.

To notify that the cursor is inside text with associated comments - one solution would be to add some text like "comment start" and "comment end" for each region of comments. You can try adding the following CSS:

Code: Select all

.oxy-marker[data-type="COMMENT"]:last-of-type:after {
    content: "comment end";
    position: absolute;
    display: block;
    top: -999px;
    left: -999px;
}
.oxy-marker[data-type="COMMENT"]:first-of-type:before {
    content: "comment start";
    position: absolute;
    display: block;
    top: -999px;
    left: -999px;
}

.oxy-marker[data-type="COMMENT"] .oxy-marker[data-type="COMMENT"]:after {
    content: "";
}

.oxy-marker[data-type="COMMENT"] .oxy-marker[data-type="COMMENT"]:before {
    content: "";
}

Re: Screen reader accessibility of tags, review comments, and validation issues

Posted: Mon Sep 28, 2020 8:59 pm
by david.badger
Thank you for the information. We were able to implement your suggestion of using CSS to clue in a 508 user of the comment anchor's beginning and end.

Would there be a way to somehow also implement this for validation issues as well?

Thank you for adding a feature request to make the comment hover tooltip keyboard accessible. I think this is likely the desired solution. However, users would also need to be able to do the same with the validation hover tooltip.

Re: Screen reader accessibility of tags, review comments, and validation issues

Posted: Tue Sep 29, 2020 5:29 pm
by andrei_popa
The comment hover tooltip and validation hover tooltip share much of the functionality, I've mentioned both in the request for keyboard accessibility. If one will get it, so will the other.

Since nesting of validation issues is less likely, I think the intended behavior is to announce start/end of each validation issue.
You can try adding the following CSS:

Code: Select all

.validation-info:before,
.validation-warning:before,
.validation-error:before {
    content: "validation info start";
    position: absolute;
    display: block;
    top: -999px;
    left: -999px;
}

.validation-info:after,
.validation-warning:after,
.validation-error:after {
    content: "validation info end";
    position: absolute;
    display: block;
    top: -999px;
    left: -999px;
}

.validation-warning:before {
    content: "validation warning start";
}
.validation-warning:after {
    content: "validation warning end";
}

.validation-error:before {
    content: "validation error start";
}

.validation-error:after {
    content: "validation error end";
}