I worked for Moltin for several years, but my role was more about building sites than designing it. However! As sites need to be responsive, i.e. work on different screen sizes, and our designer mostly provided designs for the largest viewports, I was given free reins to make sure the designs worked in all screen sizes. It can be tricky to discover all accessibility issues and considerations while creating static designs, which is why building things can be so helpful and important, as you get to actually test how it all works.
I would link to the actual site, but the company has been bought, and their site replaced. Of course there is the Wayback Machine, a web archive where you can see old versions and even defunct sites, but from time to time certain design aspects aren’t fully replicated.
My approach for this site was to ensure I got the content order right first, which then helped dictate how the the smaller viewports would look. Of course on the smallest viewports like mobile phones the content would often be one long list of content, but that reading order also needs to make sense when the design seen in bigger viewports. Keeping the reading order as straight forward as possible is also important to make things easier for users using keyboard navigation (there are usually more of these than you’d think).
Many of the pages contained a lot of links, often styled as call to action buttons. We tried to make sure we didn’t reuse the same link text over and over on the same page, as this could become quite confusing and in part too repetitive for screen reader users. This was enforced not just within the design and development, but also flagged with our marketing and content creator teams.
Accessibility is a topic I’ve been pushing to get right in my work, which has to be done as a collaboration between designers, developers and content creators. One place accessibility may be more visible for most users is on the forms. I worked closely with our designer to ensure our contact form had clear focus and error states, which weren’t dictated only by colour. And I know; using placeholder text as labels for form elements is a big no-no, however, the form uses actual labels which are completely accessible to screen readers.
While the design of the Moltin website kept changing and updating, we also changed the backend it a few times. When I first started working on the site it was moved to a Jekyll site, where the site content was built in Markdown and Liquid. Later on we moved to using a CMS to make it easier for non-technical staff to update the site.
In both instances of the site we aimed to use reusable components to make it quicker and easier to build pages, but without the need for full designs for each page. This became more important as we moved to a CMS, as we had more staff who were in charge of creating content and updating the site. Of course, there are plenty of areas which were our designer wanted to add more flair through different background colours and elements, which had to be styled and added on a per-page basis.