So the idea I have is a passage of text, with actions listed at the bottom.
Some of these actions take you to another passage, which is not part of the main game progression. It would be a passage for describing the outcome of the action, or extra description for looking at something closely. The link at the bottom of these side-passages would just lead back to the previous passage.
Here’s the thing, though:
If I added a heading just above the actions list, would this reliably allow screen reader users to skip the passage text and go straight to the actions? I’d rather not make a screen reader user listen to a whole passage every time they return to it. I think passages in Sugarcube 2 use Aria-Live, but I’m not sure what priority it’s set to, and if it’s possible to skip it and go for the actions, for anyone return to a passage.
I’m starting from as vanilla of a build in Sugarcube as possible, and slowly adding complexity to make sure accessibility doesn’t take a hit.
My approach would be to put those links at the top in source order and at the bottom visually, so the screen reader should read them first.
To do that, put the elements in a grid or flex area, and then either use grid-area for grid or order for flex to change the order they display on screen.
I’m doing this in my Ectocomp game. Where notifications appear at the top of the screen, but are actually generated last and then displayed at the top with a grid.
Depending on the content of those “Side” (child) passages, and if they always directly return back to the “Main” (parent) Passage without involving transitions through other “Side” (child) passages, you might want to consider using a Dialog instead. Because that way the “Main” Passage is never actually transitioned away from, so no return transition is required.
eg. The end-user visits the Library Passage, then selects a “Read Sign” link that opens a dialog that contains the contents of the Library Sign Passage. The content of the Library Passage is hidden behind that of the dialog, and that content becomes visible again when the end-user closes the dialog.
This Dialog related technique is often used to show information accessed via links in the Left Sidebar area, because it allows the end-user to remain in the current visited Passage.
I was considering dialogues, but also wasn’t sure how screen readers handle those. I’ll make a point to create a test scenario and try it with my own screen reader. Thank you~
Okay, so for context, I have been seriously disappointed by web browser dialog boxes for their accessibility problems many many times before, so I think at this point I had just been assuming that dialog boxes were always a terrible idea.
I can confirm, however, that dialog boxes works excellently in Sugarcube 2 with my screen reader, so I’ll be using these for “side-passages”. Thank you for the guidance.