As a developer, I did not consider accessibility like I should have. And most of the time it was more because I did not realize how simple it could be to at least provide some basic support.
This is why we added the following chapter to our contribution guidelines for UWP Community Toolkit:
- Your control must be usable and efficient with keyboard only
- Do not use custom colors
- Add AutomationProperties.Name on all controls to define the controls purpose.
- Use Narrator Dev mode to test the screen reader experience.
Let’s have a deeper look on each of these topics.
Your control must be usable and efficient with keyboard only
This is an easy one to test: Unplug your mouse and try to use your control. If you can use it in an efficient way (i.e. without becoming mad) then you are good to go.
If not, then you must think about the following options:
- Use IsTabStop=false to avoid moving the focus to unwanted area.
- Define correct Tab order using TabIndex
- Ensure that all focused controls are visible
So basically, you should be able to use Tab key to navigate between control’s area (in a logical way like top to down).
Selecting a button or an action with Enter key must also be enabled by default. If you are using stock controls, you should be fine.
But for some really custom controls, do not forget to add it by handling key up/down events.
This is also important for controls with moving parts. For instance, I had to manually add support for Left/Right manipulation on the RangeSelector to allow the user to manipulate the thumbs with keyboard only:
Do not use custom colors
Custom colors can be a problem if the user wants to use high contrast theme. As they are statically defined, they will not update accordingly to the user needs.
So just avoid them and instead rely on Theme colors like this example for the HeaderedTextBlock:
You can find the list of theme resources here: https://msdn.microsoft.com/en-us/library/windows/apps/dn518235.aspx
Another easy one. Just add an AutomationProperties.Name attribute to control which can have the focus. This will be used by the narrator to “read” your UI.
Please use self-explanatory text like “Button to create an order” instead of “Button1” and don’t use the same Name on two different elements unless they have different control types
Example here for one of the ListView used by the HamburgerMenu:
Please note that Name is minimum, but there are some other things too that can really help the screen reader: https://msdn.microsoft.com/en-us/library/ff400332(VS.95).aspx
Use Narrator Dev mode
You can start the narrator by pressing [WinKey+Enter].
Then you should ask yourself if the information is sufficient, meaningful and helps the user navigate and understand your control. Close your eyes, only use the keyboard and try to use your control.
If it does not work, then you may have failed one of the previous steps .
Call to action
If you want to help the community creating more accessible controls, we created the following issue where we track the current state of UWP Community Controls:
Feel free to take one control from the list and apply the recipe I presented here.