Achieving authentic accessibility
Web accessibility is a crucial subject – it is something that needs to be factored in at the outset of every site build, rather than hastily considered at the last minute. The digital needs of users can often be complex, but it shouldn’t require too much effort to ensure that a site is accessible. A safe approach to development is progressive enhancement – starting with a basic, clean site that is accessible to all, and then gradually adding more advanced features with CSS and JavaScript further into the site’s lifecycle, as user need and increases.
Over the years, a number of standards, guidelines and laws have been formulated to meet the growing needs of web users. The Web Accessibility Initiative (WAI) was formed in 1997 to promote web accessibility. The WAI released the Web Content Accessibility Guidelines (WCAG) in 1999, featuring 14 guidelines, each with a number of checkpoints at three priority levels: P1 (must be fulfilled), P2 (should be conformed to) and P3 (may be addressed). Only if a document meets all of the priority-level checkpoints could it be described as conforming to the WCAG.
Version 2.0 of the WCAG followed in 2008. Version 2.0 is based on four core principles; that content should be perceivable, operable, understandable and robust. There are also 12 main guidelines which are subdivided further. Each one of these guidelines has success criteria ranging from level A to AA to AAA, the latter naturally being the highest. Guidance is given on understanding the criteria, meeting the requirements to satisfy them and typical missteps made.
Connect has invaluable experience of developing websites to be WCAG (levels A, AA and AAA) compliant, allowing us to subtly and efficiently address the needs of users with visual and physical disabilities. Our work on the recently launched, BigChip Award winning SENDirect platform highlights our experience.
Simply put, ensuring that a site is accessible is just the right thing to do. Building accessible websites makes the web better for everyone, and that’s a standard that we stand firmly behind.
Pesky web plugins
However, developing with accessibility in mind isn’t always the easiest process – particularly when relying upon third-party web plugins that are intended to be compatible with the web’s most popular content management systems.
The official WordPress plugin repository, for example, is the largest collection of free and open source plugins on the web (aside from GitHub). When submitting plugins, developers are required to submit a ‘readme’ file that details the plugin’s purpose and documents the update process undertaken by the developer.
However, many developers fail to update their ‘readme’ files, despite rolling out advanced versions of their plugins, leaving other developers unaware of any changes that could impact the accessibility of third-party sites.
Herein lies an accessibility issue that we believe is hampering development and making intrinsic accessibility that little bit more difficult to achieve, when it should in fact, be an effortless and natual process.
The main bugbear that we routinely come across is the process of selecting the appropriate plugin that meets the client’s demands. When developing, we have to be aware of the client’s accessibility requirements (WCAG), and the quality of the HTML/CSS that is rendered by any third-party plugins that are used on the site.
This issue applies to web plugins for almost every CMS out there (we work with Umbraco and WordPress regularly, but have also found there are just as many issues with Joomla when we work with that platform).
To provide context: a requirement for a site build may be to feature an event calendar on a site. If a developer has never incorporated an events calendar into a site before, then they would generally search the chosen CMS’s plugin repository for inspiration. There is usually quite a lot of choice at this point, but a number of plugins usually stand out due to higher user ratings, or perhaps a crucial feature specified by the client may help narrow down the search. From here, the plugin is configured, installed and development continues, to budget and on schedule.
However, as the development phase comes to an end, an accessibility test will be run, and it is here that a number of serious compatibility issues are exposed, when the content is rendered by the newly-installed plugin.
If the plugin is closed source then a long dialogue will have to begin with the developer, who may be unaware of WCAG, and will need to rethink and rewrite the code. This is likely to be a costly process, particularly in terms of time waiting for the plugin’s developer to release an update for the plugin. In some cases, the developer may seek remuneration for the work. In the worst case, the developer simply may not be interested in further developing the plugin.
If the plugin is open source, then a technically-minded developer can dive into the code and begin to fix the issue. This is also likely to incur costs during development, but at least the developer is in control of that process.
A developer must also face the prospect that irrespective of whether or not the plugin is open or closed, there is a chance that the chosen plugin is simply unfixable; another plugin will need to be selected, the output will need to be restyled, any integrations or data imports re-coded and the client will need to be briefed about any pressing functionality changes. This can be an incredibly expensive process, and for smaller agencies, may be too much of a hurdle to overcome in order to continue with the build.
Connect has a considerable amount of experience in dealing with the cases outlined above, but fortunately we have the technical ability to make a misbehaving plugin work as it should, the industry experience to select the correct plugin for the job in the first instance, and the programming expertise required to write bespoke plugins, for when nothing out there matches the client’s requirements.
We also have a technical matrix of CMSs and plugins which quickly highlight the compatibility, functionality and accessibility levels of the plugins that we regularly use.
However, not every developer is as skilled or as experienced as our team of digital technology specialists.
Pulling the plug(in)?
So, who’s to blame? Third-party developers who fail to update their crucial files? Maybe! A little transparency goes a long way, and in 2015 developers should be clear and upfront when it comes to their approach and practices. However, we’re not looking to point the finger with this blog post – we just want to see a web that is accessible to all.
The Internet plays a significant part in all of our lives now, and it needs to be functional in order for it to play that part as intended – let’s get to work and fix antagonistic web plugins so we can ensure that the web is accessible to all those who rely upon it.
This blog post features insight from Adam Bowen, Connect’s Technical Lead.
Comments are closed here.