This will be fixed in the next build.
When the accept request completes, it does two things:
- Mark all answers as unaccepted (in case we're unaccepting or switching accepted answers).
- Mark the newly accepted answer as accepted.
To do that, I have a helper function that switches the ARIA state and sets the appropriate classes:
function setSelected($el, value) {
$el
.attr('aria-pressed', value ? 'true' : 'false')
.each(function () {
var selectedClasses = $(this).data('selected-classes');
if (selectedClasses) {
$(this).toggleClass(selectedClasses, value);
}
});
}
Unfortunately, when I rehighlighted the selected answer, I omitted the value
parameter:
// reset old accepted answer checks
setSelected($links, false);
// server sends down which vote type id was successful, either accept or undo
if (parseInt(data.Message, 10) == voteTypeIds.acceptedByOwner) {
setSelected($clicked); // BUG
}
Since value
is undefined
and undefined
is falsey, the button got stuck with aria-pressed="false"
. This bug didn't surface so dramatically visually because toggleClass
has a different behavior if the second parameter is missing or undefined
, so it added the visual styles which had been removed a few lines earlier.
I've also added a couple more accessibility changes while I'm in the area:
- On pages where you're not the question owner, focusing on the accepted indicator will cause the tooltip to load (previously it required a mouse enter event).
- I've replaced the loading indicator with the new visual style and set it up as a
role="alert"
so "Loading..." gets announced when you click on the accept button. (This will apply to future uses of the new loading indicator as well.)
aria-pressed
on the accept-button remains false, despite me clicking on the accept link and other attributes and classes change. IIRC the aria attributes in the DOM are used by screenreaders so that could explain that your screenreader doesn't pickup the change in state. – rene Jan 16 '19 at 20:54