When I was starting with development of some more advanced forms I would first check the availability of some JavaScript plugins that would solve my problem on the cheap. When I fast forward to today’s abundance of NPM and other packages that enable developers with hundreds of thousands of different possibilities it is even easier to do so.
But should we just reach out and add an out-of-the box solution and save the time? What risks can this bring to our product? Is it worth it?
I will try to elaborate on these questions in this post, but just to warm up:
Besides quality and security evaluations we should always also evaluate the accessibility grade of our potential new control (dependency). Sometimes saving time in the start can introduce problems later.
my considerations and suggestions for new control/dependency evaluation.
Saving time in the start can make a lot of problems later
Ok, let’s say that we needed a date picker for our form and we did not like the cross-browser situation of native date and time elements. Simple native text fields were not an option because we want our form to be usable and pretty.
So next logical step is to either create or just borrow some custom date-picker that can satisfy our acceptance criteria.
At this point we should and must also evaluate the accessibility considerations of the new widget. If we are creating it from scratch, then we have full responsibility to follow all the WCAG requirements, together with functional and design ones. But when we are importing it from a repository or some other source we should do a full evaluation before just using it. Otherwise we could introduce a huge problem later in the process.
So it may take few minutes to find a ready, community powered datepicker, but we should really invest the time to test it with accessibility in mind as well as the usability and other criteria.
What should we then check for when introducing a custom widget/control?
Before getting into all the detailed testing we can do a quick evaluation with help of the following list:
- accessibility tree exposure – does our widget reflect correct name, label, role and state – are they correct and understandable?
- is our widget operable with keyboard only, is it receiving focus and does it respect design patterns that users expect?
- does our widget allow us to fix eventual contrast issues?
With this list we can do a quick evaluation or set our basic acceptance criteria but we should expand this starting points with some real tests when we can put the widget into some testing context (like a part of a bigger form).
Besides these checks we should also check the eventual community support and if there are any known issues. Maybe some of the issues has not been addressed for a long time and maybe it is exactly the thing we need – so here we can even evaluate if we can be the contributor to fix or if it is maybe better to move on and find an alternative solution.
Some resources that may help with decisions
As you probably know – when developing new controls/widgets – we are quickly in the ARIA world and there are a lot of rules to follow. Let me just say it again – first rule of ARIA is to not use ARIA (if you can use a native HTML element – just use it).
But when we must reach into ARIA, then we should dedicate some time and do our homework – research first what is expected from our code and how the widget must comply with established patterns.
Some useful resources: