Forum Discussion
Navigate a grid by keyboard
Thanks for the reply. I agree about the Tab Key and Focus Order. I have been working on that and the ability to move in any direction is not there. I want this to work for people who cannot use a mouse and for people using a screen reader. The screen reader can use Browse Mode but the keyboard only cannot.
The beginning is the first square in the upper-left corner and proceeds left to right then down etc. No movie but when the player finds a square with a question, a light box opens and they must answer it correctly to get the point. When the player returns to the grid, it starts in the upper-left again.
I may need to use javascript to solve this. I don't see how I can use triggers to go from point to point in the slide and return to that point.
I can see the upper-left restart could annoy people by putting them back at the start. Is that slide's properties set to Resume saved state when revisiting? That tends to leave slides as I found them, but if the When revisiting parameter is set to Reset, it will do just that every time--clean slate. It's easy to miss tucked in the bottom-right corner.
I expect this is only marginally close to yours, but I spun up something here: Arrow highlights | Review 360 I've enabled download, so feel free to take the project file.
To me, Nate's design pattern frames the Battleship board as a table, which is why I numbered the nine shapes with coordinates. On screen of course, a column header can show A or F or whatever to the learner, but the arrow keys (eight triggers) just increment and decrement two variables: currentX and currentY.
The remaining triggers, two per button, control the highlight in response to the values of currentX and currentY.
Navigating using the Next Slide and Return buttons will circle you back to the grid slide where your position has been retained.
As the size of your grid/field expands, naturally the number of triggers will scale too, and the risk of errors increases. JavaScript could condense the getVar/calculate/setVar/updateState loop significantly.
I imagine event listeners on keys could all call the same move function, passing their cardinal direction as an argument, and then a simple case system updates the currentX, currentY, and state. Some of the greatest effort might be collecting the object IDs of all the squares so the script can highlight the right one, but this assumes your project mirrors what I've shared. Lemme know