We work on the Internet and are constantly consuming information. There's a lot of it out there. We'd forget it if we didn't write it down someplace…
Visual Lizard's blog covers everything from web standards to the muppets, from php to comic books to music, just about anything we find interesting
Recently one of the projects I've been working on is to assess the accessibility of a number of sites and to provide feedback to the client as to how accessible those sites are under the WCAG Guidelines at w3.org. I also recently found a link we had shared earlier this year on our own site relating to how w3.org had recently updated its site design. As a result, here I am writing an article on Accessibility.
I am not a person with disabilities. I don't really know anyone specifically that has disabilities. That being said, part of my job is to build websites that should be accessible to people of all abilities. This means thinking outside my own little world of being able to interact with websites as a fully able-bodied person. Recently I have been using tools that assess the accessibility of websites. These tools have opened my eyes and have changed how I think about the development and design for the websites we build.
The Web Accessibility Initiative (WAI) is a resource that until recently I only consulted occasionally when the need arose. I have had some time this week to fully look at some of the items that should be standard reading for any web designer or developer. The rules and recommendations found at the WAI may sometimes seem counter productive to a slick design for websites, but in actuality they force designers and developers to rethink their understanding about the website's or web application's audience. Not everyone interacts in the web environment in the same way. We need to remember that when we're developing our web projects.
As a developer, my specific job is to translate a design into a functional interface. I get significant enjoyment out of doing that. What I had not fully realized until recently is how significant that underlying coding can affect how a person interacts with the interfaces we create. Colour, contrast, and structure play a more important role than just setting up a visual interface. For people with disabilities, those elements of a design and development process determine whether that interaction is helpful or impossible (or somewhere in between).
We've developed our own Content Management System (CMS) over the years, and one of the things we're most proud of is that we've set it up to build out our pages and functionality with accessibility in mind. There are still things we can improve on (and we continue to do so), but we've done a pretty good job of making accessibility a priority. We also advise our clients to keep accessibility in mind when they are supplying content, and we make ourselves available to provide advice on best practices.
Accessible interfaces can be hard to implement. Functionally, we can do it. The difficulties come when a design is provided that is by its nature not accessible. The design may not take into account contrast requirements, or they have definite ideas on how interactive elements should be presented. We do not want to get in the way of those creative ideas, however we do need to be able to say no. Accessibility is no longer just an aspiration, it is now, in some cases, required by law.
During the time we've been involved with these accessibility assessments, one of the primary issues we've found is that certain prolific CMS platforms are very good at the very root level of accessibility construction for web pages, but many of the custom plugins that are used to extend the functionality are very poor at maintaining the level of accessibility required to meet the legislative standards.
We're not saying that all of these plugin developers are creating poor code. The more reputable plugins have been developed with accessibility in mind. The problem there is that the plugins environment is sometimes a bit of a Wild West. The root platform developers want to make it relatively straightforward to extend their platform, but that means there is little to no standardization required for plugins to be approved. As a result there are some pretty terribly coded plugins out there and the average person can't tell good from bad.
Some highly advanced sites we reviewed were developed with custom code. We would expect that the custom development would follow at least the minimum accessibility standards that are required today. Surprisingly we found dozens of accessibility errors and alerts that could easily be mitigated by running some simple accessibility testing.
During our development of sites and web applications it is our standard practice to run our pages through automated tools to check for deficiencies before we prepare to launch to the public. We use the WAVE WebAIM tool to provide us with a report on how our underlying code stacks up to the WCAG 2.1 standards set by w3.org.
We will continue to endeavour to make sure our own CMS lives up to the accessibility standards set out by the W3C. We will also continue to provide accessibility advice to our clients to help them put their best foot forward in providing their information to people of all abilities. We want to continue to help our design partners be aware of accessibility during design development so that any accessibility design issues can be addressed preemptively.
Not everyone interacts with the online world in the same way. If we remember that, the world becomes a better and more inclusive place.
PHP 8.1 required. Improved typehints across the framework. CakePHP now leverages union types to formalize the types of many parameters across the framework. Upgraded to PHPUnit 10.x New enum type mapping support in the ORM enabling more expressive model layers with improved type checking. Table finders with named parameters, providing more expressive query building APIs. Added time-only Time type and greatly improved Date and DateTime support via chronos 3.x. Support for PSR17 HTTP factories was added.