I recently reviewed a web-based file manager for accessibility. It was laid out as a table, with information about each folder or file inside its own row. Each item could be opened by clicking it’s name, or selected via a checkbox, for further manipulation.

Above the table was a set of action buttons such as “Move”, “Rename”, “Delete”, etc. These buttons would appear when one or more items in the table were checked, and disappear when no items were checked.

This worked well for folks who could see, but posed a problem for screen reader users. How would a blind user know that the action buttons had appeared? We could have added an ARIA alert, but that probably would have been more confusing than helpful, and wouldn’t have help screen reader users know where to find the action buttons.

The solution we ultimately adopted was to not hide the action buttons at all–at least not for screen reader users. Instead, we made the buttons hidden for everyone except screen reader users, and marked them as disabled. That way, since they came before the table, screen reader users would see them, and they would hopefully deduce that if they wanted to perform any of those actions, they could do so after selecting the files or folders.

The takeaway from all this, in my view, is that when causing new controls to appear on screen, that are far from where the screen reader user is currently “looking”, can require some careful consideration to ensure that the user knows that they have appeared, and where to find them. I am not aware of any clear solution to this problem, and I believe that it is best avoided if at all possible.