CODEWITHSUNDEEP
accessibilityvoiceoverscreen-readerswcagnvda
siva
siva

Reputation: 525

Implementing accessibility inside the grid

I am developing a grid with many rows and columns with accessibility compliant. I am facing few issues here...

The user can construct the geometric shapes inside the grid by clicking on each point. They can also drag each point to another location inside the grid.

enter image description here

I am thinking of making each point in the grid accessible using the tab focus. However, I am not sure how to announce to the user meaningfully when they try to construct the shapes in the grid (like when they reach a point in the grid, what should the screen reader say?) and how to make each point draggable and announce to the user?

Upvotes: 0

Views: 278

Answers (1)

slugolicious
slugolicious

Reputation: 17455

Depending on what else is on your page, I would probably make the entire grid one tab stop and then use the arrow keys to navigate through the grid. It makes tabbing to other interactive elements on the page (links, buttons, checkboxes, etc) a little easier. If the entire page is made up of just the grid (ie, nothing else to tab to on the page), then you could probably use tab to navigate through the grid.

Assuming you go with the arrow keys to navigate, you could use shift+arrow to perform the actual move. So I could arrow right five times then arrow down once to get to your northern most point on your example. Then I could use shift+rightarrow to move that point to the right.

Alternatively, you could arrow to the point and go into an "edit" mode by pressing enter and then you wouldn't need shift plus the arrow key to move the point. You could just press an unmodified arrow. Pressing enter a second time could save the point change and toggle you back out of "edit" mode. escape should cancel the move.

Creating a new point could happen by pressing enter on an empty grid intersection.

As you arrow through the grid, you'd want to hear if there's an existing point at the intersection. If there's no point, then you don't need to announce anything other than the grid coordinates (row,col). If there is a point, then after the grid coordinate, say something like "point". If I start in the upper left and arrow right and then down to get to the eastern edge of the shape, you'd hear something like:

  • arrow right "1, 2"
  • arrow right "1, 3"
  • arrow right "1, 4"
  • arrow right "1, 5"
  • arrow right "1, 6"
  • arrow right "1, 7"
  • arrow down "2, 7"
  • arrow down "3, 7, point"
  • arrow down "4, 7"
  • arrow down "5, 7, point"

(Whether the upper left is 0,0 or 1,1 probably doesn't matter. Just pick one.)

As far as the role of the points, there isn't really a good built in role. A <button> comes close but doesn't imply you can move it around. This is probably a good case to use aria-roledescription. You might have to use the application role, which I rarely recommend, but you'll want all keyboard events to be sent to your grid rather than be interpreted by the screen reader. Without the application role, pressing the arrow keys would send the keyboard event to the screen reader which would read the next word or line on your page. Using the application role automatically causes the events to be sent to you (so you can have an event handler in JS).

If you don't use the application role, the screen reader user can still interact with your grid but they have to manually switch modes to do so. It's pretty easy to do but you'd have to notify the screen reader user that they need to switch.

I hope that's enough to get started.

Upvotes: 1

Related Questions