Marie was invited to speak at Dot All 2022, the official Craft CMS conference, in Brooklyn, New York, USA.
The talk was about our accessibility takeaways from the W3C website redesign project.
From choosing a CMS with an accessible editing experience to producing a website that is compliant with Web Content Accessibility Guidelines, accessibility was a recurring theme when we redesigned the W3C website.
Marie took delegates through the process of producing accessible websites and shared resources we produced including Amplify, our accessible front end starter kit.
A list of resources mentioned in Marie’s talk at the Dot All 2022 conference can be found on our blog.
Transcript
| Audio | Visual |
|---|---|
| [Instrumental keyboard music] | [Dot All Conference logo and a photo of New York’s Brooklyn Bridge and skyline] |
| [Instrumental keyboard music] | Thank you to our sponsors:
|
| [Instrumental keyboard music] | Marie Manandise Accessibility Takeaways from the W3C Redesign |
| Can you all hear me? Yeah, [inaudible]. | [Marie at a podium, with the slideshow presentation on a large screen behind her] |
| It’s awful to speak last. I was so nervous that my Garmin watch thinks I have been exercising all day. [Audience laughter] It’s been beeping to tell me “you’ve got your exercise quota,” alright? So be nice. | [Marie gestures to the watch on her wrist] |
| Right, so my name is Marie Manandise and I’m a Front-End Team Lead for the Studio 24 digital agency that is based in Cambridge, in the UK. And we’ve had the privilege of working with W3C to redesign their website. If you don’t know who W3C is don’t worry, I’ll explain. At this stage of the conference, I’m assuming total ignorance and that our brains are fried. So this talk is about accessibility takeaways from this project. | Accessibility Takeaways from the W3C Redesign Marie Manandise, Studio 24 |
| I’m going to explain what the W3C redesign project is, how accessibility was a recurring theme when working with W3C, and it will also explain what I’m doing here talking to you about accessibility at a Craft conference. |
|
| I will then spend a fair amount of time talking you through the process of making accessible websites – actually, the rest of the talk is pretty much an excuse to get you there to talk about that and then I’ll introduce you to a few resources that we hope you can use to kick start your journey into accessibility and that came as a consequence of that work with W3C. | [Marie at the podium] |
| For those of you who are missing their browsers already, this is the link to a page on our website where I’m listing all the resources mentioned in this talk. So, no need to frantically type everything you see, it will be on there. | List of resources mentioned: https://studio24.net/blog/dotall2022 |
| So, let’s talk about that project. | W3C redesign |
| Meet the Studio 24 team, posing here for their latest album. It’s just a company picture that we took last time we gathered together in our offices in Cambridge. [Audience laughter] So we’re a modestly sized agency. We’re not small, but we’re not huge. | [Outdoor group photo of the Studio 24 team standing in front of their office space] |
| And if I have to give our most defining characteristics – and so we’re very big on web standards and best practices (and I’ll define what I mean by web standards in a minute) and we’re very much committed to accessibility. For a number of years now, we’ve been working with public sector organisations to make their websites and most of these have accessibility as a legal requirement, so we need to make that happen. |
|
| Here’s a screenshot of most of the staff of W3C or the World Wide Web Consortium. W3C was founded by Tim Berners-Lee himself, so, the inventor of the web, in 1994. So really in the early days of the web as we know it – as something like global and, you know, international. | [A collection of headshot photos of W3C staff] |
| And the goal is to develop web standards and guidelines, and that includes accessibility guidelines. So, by its very nature the web needs to be standardised. To remain that big, unfragmented entity we need to all be doing the same thing. To give you a very easy, practical example: if, as developers, we build websites with HTML elements that a browser does not understand, it’s not going to work. So we all need to be patched together. |
|
| You might have come across one of those documents when you were looking for the source of truth as to how to use an HTML element or an attribute. These are the kind of documents that W3C writes. So when I say W3C, it’s not just their staff arbitrarily coming up with these rules. They, they form working groups with experts in industry and members of the public. So they try to involve as, to get as much feedback from the public as possible, and to do that they work in the open. Everything they publish or the slightest meeting memo is out there online for anyone to see and take part. I need a drink. [Marie swallowing] I had my drink. | [A screenshot of the start of the W3C Recommendation: HTML5 Image Description Extension (longdesc)] |
| Where was I? So, yeah, the Web Accessibility Initiative or WAI is one arm of W3C. And they’re the ones responsible for accessibility guidelines. By the way, so really, whether you’ve heard of them or not, W3C is really behind all the fundamentals of what you do every day. So HTML, CSS, JavaScript, they, they set the rules for all of these things; including WAI sets out the accessibility rules. If you’re interested in accessibility, this is a good place to start. They’ve got loads of material for advocacy, training, tools that you can use. | [Screenshot of the homepage of the Web Accessibility Initiative (WAI)] https://www.w3.org/WAI |
| And, I don’t know if you’ve come across that concept of WCAG or Web Content Accessibility Guidelines? So that’s the WAI that organizes and publishes them. | Web Content Accessibility Guidelines (WCAG) |
| And so typically when we say, oh, we’ve got a contract, we, we need to meet accessibility guidelines, going to say I’ll get this WCAG, and then the version – we’re on 2.1, verging on 2.2 soon – and then it is going to say you need to hit that level, so A, double A or triple A. So, among the guidelines some of them are very basic. A – like, just enough, enough contrast, for example; have a transcript with videos. Double A is what we refer to as the legal standard. So, in most contracts it’s going to be WCAG 2.1 double A. For example, having captions in videos. And then triple A is the gold standard – you have sign language in your videos, and that kind of thing. | WCAG X.X (A) (AA) (AAA) [X.X indicates the version] [A, AA, AAA indicates the level] |
| That’s what the W3C website looks like at the moment. Not very exciting. So, it’s been looking like that for a fair number of years. It’s difficult to find your way around it. It’s been accumulating content for decades. It’s one of the oldest websites on the web. So, you know, a few years ago, or five or six years ago, they had the first attempt at having it redesigned with an agency. For some reason I’m not privy of, it fell through. But two years ago, they again asked for candidates to rebuild and redesign their website and lo and behold they awarded the contract to us: Studio 24. Now, this was very exciting for the team. It was also frankly terrifying and intimidating because, you know, they’re the biggest authority in the industry, quite frankly. | [Screenshot of the homepage of W3C, prior to the redesign project] |
| So, it goes without saying that the web pages of their website needed to meet WCAG, web accessibility guidelines. And that was not a ‘best effort’ requirement, that was really a ‘lead by example’ requirement. If the W3C pages do not follow their own guidelines, who will bother honestly? So, that was one requirement. A less common requirement was that the CMS that they’d use to power, to hold some of the data, would have an editing experience that meets those guidelines. We’re not talking about the pages that are rendered by the site, but really the interface needed to have that. And that’s where I came into the project. |
|
| I came into the project, it had been running for five or six months, but I came in fresh out of maternity leave and a very strict lockdown in Belgium. Sleep deprived, still breastfeeding, clearly on the floor, going back to work thinking ‘Okay, you’ve got two kids now. Don’t get too drawn into work’. And the first task I’m entrusted with is to look for a CMS for what I personally consider the highest authority in my industry. [Slight audience laughter] Life has a way like that. So, I just set to work. There were loads of requirements. It was already kind of difficult and felt like you know, a lot was at stake in making that choice. We needed a strong API because we wanted to start a headless architecture. | [Selfie photo of Marie sitting at a desk with an open MacBook, a separate keyboard, a notebook, and her baby son sitting on her lap] |
| We needed to have good multilingual support out of the box. We needed a granular definition of our content model and fields and stuff. So, of course, Craft therefore was on our top three preselection of CMSs. But where we really got stuck is to try and find a CMS that was accessible in its interface. Yeah, that was really difficult because just even just finding that information, those reports, about how accessible, the level of accessibility of the software is – it just doesn’t exist, quite simply. I naively assumed that the big guide had it under control, but then when I scratched below the surface I couldn’t find any information. The accessibility statements that I could find were vague. It was not really clear how the accessibility team’s efforts were plugged in with the main development efforts for the Content Management Systems. | [Marie at the podium] |
| So yeah, that was um… sorry again. That’s just a little thing I have when I talk in public. [Marie swallowing, slight laughter in the audience] A nice er slurping sound for the, you know. | [Marie takes a drink from a bottle of water, then gestures at the microphone] |
| Okay, so, we had to review that criteria and work differently. We had to resort to liaising directly with CMS vendors and say ‘Okay, who’s ready to get on board and to work with us?’ It didn’t have much support. We didn’t have much resources to help them. But, you know, who’s ready to change their ways of working to include accessibility and to be compliant by the time, ideally by the time, the site launches? And that’s where Craft’s response was brilliant. Brandon proactively got in touch and said ‘Well guys, we’ve actually made a commitment to become compliant by version 4,’ which in hindsight was a bit over-ambitious, but at least, you know, that gave us a first sense of okay, so they’re interested, our values are aligned here. And I know it can sound a bit, like, fluffy to say that, but it has practical implications when that happens. And then really what sealed the deal is in further conversations with them, we really understood that they were ready to change their ways of working to embed accessibility as part of their development process. So we thought ‘Yes!’ And that’s how we selected Craft to power the W3C website. Um, yeah. | [Marie at the podium] |
| So, if you want to know more about this CMS selection saga, you can read everything about it in our working in the open site. So, I said W3C works in the open. One of the conditions of our contract was that we had to work in the open too, so everything we were doing was documented – all our reasonings, and choices and everything. Which, by the way, it takes time guys. If you ever have that in a contract it takes a lot of time and you’re under a lot of scrutiny. It was, it was fun. It was a good exercise, but it was, yeah, pretty hard. So yes, go and check it out. | [Screenshot of the CMS Selection Report article on the W3C / Studio 24 Working in the Open website] https://w3c.studio24.net/docs/cms-selection-report |
| And now for one of the most satisfying before and afters of my career so far: that’s the W3C website homepage and that’s the beta website that you can see. It is public: beta dot w3 dot org. It’s not finished. I mean, they’re still populating content, but we’ve handed it over to them. They’re still integrating a few systems, and, yeah, I find it quite refreshing to be honest. | [Screenshot of the homepage of W3C, prior to the redesign project, followed by a screenshot of the W3C beta site homepage] https://beta.w3.org/ |
| And that’s the team who worked on W3C ringing our bell, in our messy office that we ring when we launch a website. As you can see, I’m wearing my lucky t-shirt. [Audience laughter] Um, I have other clothes, but I really like that one. [More laughter] I promise! | [Photo of the team at Studio 24 who worked on this project, in their offices and happily ringing a large bell. In the photo Marie is wearing the same Tiger t-shirt that she is wearing during this talk.] |
| So, what is that process of making, you know, to make accessible websites that Studio 24 has followed to reach that goal, and that Craft is building up to, to reach accessibility compliance? First of all it’s a process, okay? So it’s not a one-off task that you just slap at the end of development and then forget about. It’s an on-going process. If there’s one thing you need to remember about this talk, it’s that. I can now lose your attention and I’ve done my job, to a certain extent. It’s more fun to listen, but there’s that. | The process of making accessible websites. [Three large red arrows and scribbled circles emphasise the word: process] |
| A bit of a boring slide and there’s a lot on it, but it’s going to stay with us for a bit, so let me run you through it. That’s a very rough timeline of a project. For us it’s a project, for you it can be a release cycle, it can be a sprint, depending on how you operate. So you have on top left some planning – that’s resources planning. That’s really, you know, the PM’s job, the Project Manager’s job: who does what, when, what budget. And then ongoing project management. You’ve got a design and usability phase. In parallel to that or before or after, a technical specification phase where you choose your tooling, you choose your approach. Once you’ve got all that you go into development. Then you have quality assurance followed by repairs – let’s not forget to factor in repairs after auditing. At some point content authors are going to populate the content via the CMS. At some point the maintenance team is going to take over, for further changes and stuff. | [Top (first) row:] Planning, Project management [Second row:] Design/UX [Third row:] Technical spec [Fourth row:] Development [Fifth row:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| And now what I’m going to do is I’m going to tell you the story of a web developer who starts gaining awareness of accessibility, through to the moment where the whole team’s on board and they’ve nailed that process. And every time there’s one of these steps that includes accessibility, I’m going to turn it red and add a bit of an accessibility icon to it. Notice that I don’t just rely on colour. I’m going to add an icon because that’s not accessible to just rely on colour. This talk is accessible. Let’s get started. | [Marie at the podium] |
| So I’m going to have a drink. It’s, it’s becoming my thing. [Marie swallowing] | And so the story begins… |
| So you’re a web developer, you went to a conference, you heard about accessibility or you read a blog post about it. And it really resonated with you. You’re a good person, you want to make the world a more inclusive place. You have an opportunity to do that in your day-to-day job, and that’s amazing. So, you go back to your desk and you think: ‘from now on all the websites that I’m building, they’re going to be accessible.’ So you go back to your desk, you look at your current project and you wonder: ‘where do I start? How do I even know that what I’m doing now is accessible or not?’ So you look for assessment tools and you might come across, for example, we use the Axe DevTools at Studio 24 for assessing our own work. | [Marie at the podium] |
| It’s something that you add to your browsers, it’s going to add a tab to your – here in Chrome – to developers tools. You run it against web pages, it brings up a number of issues and a description for them. [Marie coughs] Sorry. | [Screenshot showing the axe DevTools in the Chrome browser] https://www.deque.com/axe/devtools |
| And I don’t know about you, the first time I used a tool like that I felt completely stupid. There’s a few issues that make sense because they’re about contrast or missing alt tags to images. That makes sense. Then there’s a whole series about aria labels and focus states that you’re not clear on. | [Photo of a dog sitting in an office chair facing a monitor. Its paws are on a keyboard. The accompanying text reads: I have no idea what I’m doing.] |
| And then there’s going to be a few that look like false positives, like, due to the automation of the test, but you’re not confident enough to dismiss them. So, okay, so we’ve asserted that at development you need, developers need, a certain level of knowledge about accessibility, they need self-assessment. But you’re pressed against the deadline, you’ve got to get this website out of the door, it’s not going to happen. Next time. Next website that I’m building, I’m going to make it accessible. Now, the fact that I start with the developer is not an innocent choice. It’s because most of the accessibility guidelines, they’re about markup, and well, the semantic markup. So there’s a fairly widespread misconception that accessibility, the responsibility for accessibility, relies almost squarely on the developers’ shoulders and we’re going to see that it’s not that simple. Yeah, we can’t just work our magic to code and suddenly out comes an accessible website. So, next project you’re really raring to go. You’ve, you know, you’ve learned a lot more about HTML and accessibility and all those rules. So you’re waiting for the design and the designer hands you this. | [Marie at the podium] |
| [Some background noise from the audience] Disclaimer: it’s not a real design. Okay, that is very bad. No designers that I know and respect would produce that. Apologies if you recognise any features that are from your [inaudible]. But, you know, it’s bad, but when you think about it, there’s some elements of it that are not that uncommon. How many times have we got a big splash picture with text overlaying it? And then at one screen size or another it’s not going to work out with the contrast. So you get back to your designer and you go ‘Er, have you heard about accessibility? Can you review this? Can you change that?’ And then you’ve got the project manager behind your back going ‘We don’t have time for this. It’s another design review, it was not factored in, we don’t have the budget and what are you doing?’ | [A mockup design of a fictional website. The main navigation bar contains extremely low contrast text. There is a full page background image of an African landscape with hippos. The breadcrumb navigation has poor colour contrast against the colour of the sky. The main text content sits on top of a slightly translucent white background colour, so the background image remains partially visible.] |
| The designers were going to be busy, I’ve got other projects to get on with, I don’t have the time. Also, they are probably going to resist a little bit because it feels like yet another constraint on their creativity. And let’s face it: I think designers get a bad rap sometimes for having that attitude, but talking about, you know, Sarah [an earlier speaker] told us about empathy. It’s important to realise that the web of, the job of making websites both from, from, for developers and designers is becoming more and more complex and constrained over the years. It’s for a very good reason – here accessibility – but I think it would be easier and more productive to move forward to admit that, you know, these things are difficult to digest and then to change your habits. But okay, awareness of accessibility has reached the design department. | [Marie at the podium] |
| So they’re going to pay attention to contrast, legibility – there’s a maximum width of long text that is easily scannable, interactions – so leave enough spaces around buttons so people with tremors, on mobile, can still hear them… so all these things need to be taken into consideration. [Marie swallowing] Mm. Now, clearly you don’t have time for, you know, in the context of this project you agree with the designer, okay. Next time we know what to do, but this time it’s not going to happen, so. Next time, the next website is going to be accessible. | [Top (first) row:] Planning, Project management [Second row, now in red and with accessibility icon:] Design/UX – contrast, legibility, interactions, … [Third row:] Technical spec [Fourth row, now in red and with accessibility icon:] Development [Fifth row:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| And actually accessibility has now reached the ears of management and sales. Because as your agency is growing, you’re starting getting bigger clients, including in the public sector or international organisation that have accessibility as a necessity or, or a legal requirement. | Accessibility as a legal requirement. [World Wide Web Consortium (W3C) logo, Royal Coat of Arms of the United Kingdom, UNESCO logo and USA.gov logo] |
| When that happens you’re going to have to write an accessibility statement that shows that you have gone through an accessibility audit and then of course it’s going to be followed by accessibility repairs. I don’t know if any of you have gone through that process? If you go through an accessibility audit for the first time and you’re not prepared, it can be a car crash. | [Top (first) row:] Planning, Project management [Second row, now in red and with accessibility icon:] Design/UX [Third row:] Technical spec [Fourth row, now in red and with accessibility icon:] Development [Fifth row:] QA [now in red and with accessibility icon], Accessibility audit, Repairs [now in red and with accessibility icon] [Sixth row:] Content entry [Seventh row:] Maintenance |
| Because, you know, if you felt foolish with the self-assessment tools in your browser, this one’s going to be like a massive blow. It’s a very lengthy report, long descriptions, very technical. You’re going to have to go back and forth with the auditing agency. Okay, I didn’t touch on that. When you do an accessibility audit for a legal reason like that – you need to do it via a third party specialist agency. The reason for that is that automation, automated testing, it only covers a subset of the accessibility guidelines. So there needs to be some manual testing. Ideally, you want it to be done manually by people who actually rely on assistive technology or have accessibility needs because, you know, guidelines are very good to speak the same language in contracts and to have a kind of a legal, er, yeah, a legal statement, a legal benchmark. But following standards does not guarantee that the experience for people with accessibility needs is going to be good or let alone pleasant. Just possible. So yeah, as I said, typically the first time is going to be really difficult. You probably will not have factored enough time for the repairs, You might have painted yourself in the corner with the way you’ve organised your code, so you have to review a lot more than you thought. And that’s where the project managers are going to panic and ‘why is it taking so long?’ And the client can be infected by the panic, going ‘oh, you told us you could do, you know, are you really competent? You told us you could do HTML, you know accessible HTML, and then now it comes back from audit and you’ve got those hundreds of problems…’ and, you know, so, yeah, don’t. Get prepared, please, if you, if you have to go through that. | [Marie at the podium] |
| So of course, project managers start to get aware of accessibility as well, because you need to factor in that QA and those repairs and that takes time and money and, you know, overheads. | [Top (first) row:] Planning [now in red and with accessibility icon], Project management [Second row, now in red and with accessibility icon:] Design/UX [Third row:] Technical spec [Fourth row, now in red and with accessibility icon:] Development [Fifth row, now in red and with accessibility icons:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| Okay, well imagine that this time or at some point you managed to build a website that is accessible. So that’s a very simple page. The British among you might recognize the gov.uk website I kind of ripped it off from. Okay, it’s a very simple page. You’re very proud of the fact that it’s accessible. | [An improved version of the aforementioned fictional website. The background image has been removed, content has good colour contrast and is legible.] |
| Three months later, you come back to it for maintenance and it’s looking like this. [Audience laughter] So what happened there is that an intern in marketing decided to jazz things up a little and they’ve included like a seizure-inducing gif to show off an industry award they’ve won, an auto-playing video with no transcript, and the creative use of fonts and fonts colours. So yes, content authors can wreck accessibility. [Marie swallowing] I’m going to finish the bottle at this rate. | [The improved version of the fictional website, but now featuring a video embed, an animated GIF and a paragraph of text with a custom font and colour which is now hard to read] |
| To be fair to them though, you did set them up with like one large wysiwyg field field with all the options under the sun. | [Marie at the podium] |
| Before long their eyes were drawn to this bad boy. [Audience laughter and clapping] And they realised that they could just turn to HTML mode and embed whatever they wanted, include inline styles. Yay, it’s party time. | [Screenshot of a wysiwyg editor, with red circles used to highlight the option for editing source code, and a large party face emoji for sarcasm] |
| So what can we learn from this? Uh, train your content authors to respect accessibility guidelines. So, they need to know that they need alt attributes for images that are informative. Okay, decorative images don’t need alt tags, that’s actually a lot of noise. There are writing guidelines. So I said that most of the accessibility guidelines are about HTML markup, but actually there’s a whole section about writing, so the wording itself. You need to lower the cognitive load as much as possible in the text. That’s, well yeah, a significant amount of work as well. You’re starting to see where I’m going with this, right? | [Top (first) row:] Planning [now in red and with accessibility icon], Project management [Second row, now in red and with accessibility icon:] Design/UX [Third row:] Technical spec [Fourth row, now in red and with accessibility icon:] Development [Fifth row, now in red and with accessibility icons:] QA, Repairs [Sixth row, now in red and with accessibility icon:] Content entry, image alt tags, writing guidelines [Seventh row:] Maintenance |
| Okay, that also means that, you know, as the person responsible for setting up the CMS, well, you need to set up your content model and your fields in the way that you’ll have enough control over the markup on the other side. So that’s your responsibility. Learn to set up, you know, to configurate your wysiwyg as well. | [Top (first) row:] Planning [now in red and with accessibility icon], Project management [Second row, now in red and with accessibility icon:] Design/UX [Third row:] Technical spec [Fourth row, now in red and with accessibility icon:] Development, CMS interface setup [Fifth row, now in red and with accessibility icons:] QA, Repairs [Sixth row, now in red and with accessibility icon:] Content entry, image alt tags, writing guidelines [Seventh row:] Maintenance |
| I’m not saying you should systematically turn off the HTML toggle. Actually with the W3C we had to go the other way round. We had to re-enable it and I had to white list an incredible number of tags that nobody usually uses, and that’s because they actually write blog posts to demonstrate how to use those things. Um, yeah, that was, that was fun. | Marie at the podium |
| Okay, that also means that, you know, I’m going to break all conventions and start from the bottom here. You need to choose the right CMS to do that, to give you that granularity in your content model. If you’re using third party tools, you need to check that they’ve been audited for accessibility. Or maybe you need to use the API to draw the raw data so you’ve got control over the markup, that kind of thing. The tech stack, there are tech stacks that make it a bit more complicated to make accessibility repairs. React developers, for example, and accessibility developers – they’re rarely the same person. | [Top (first) row:] Planning [now in red and with accessibility icon], Project management [Second row, now in red and with accessibility icon:] Design/UX [Third row, now in red and with accessibility icon:] Technical spec, Tech stack, Third party tools, CMS and content model [Fourth row, now in red and with accessibility icon:] Development, CMS interface setup [Fifth row, now in red and with accessibility icons:] QA, Repairs [Sixth row, now in red and with accessibility icon:] Content entry, image alt tags, writing guidelines [Seventh row:] Maintenance |
| So if you’re going to hide your markup into complex JavaScript methods that require loading, installing, and running loads of complex build tools to actually test HTML changes, chances are that your accessibility specialist, if you’ve got one, won’t be able to do it. So that’s something to factor in, you know, you will have overheads if they need to every time brief the development team to make repairs. | [Marie at the podium] |
| Okay, that’s another situation that you encounter along your journey. You have an audit on one of your websites: 28 issues. That’s actually okay. You repair them, you launch the website. | Accessibility audit report 15 June 2021 Summary of issues [shown in a table] Critical: 15 |
| Six months later it gets re-audited, because that’s something you need to do on a regular basis, and boom! 257 issues. And you go ‘What? What went on there?’ What happened is that the maintenance team took over and they were not let in on this accessibility thing. So, the client came to them going ‘Oh can we have a slide show that auto plays, can we have a video that does this and that, and, and embed this widget?’ | Accessibility audit report 15 January 2022 Summary of issues [shown in a table] Critical: 175 |
| And they never thought to stop and to go ‘I think there might be an accessibility risk here – let me consult our accessibility specialist so we can, you know, maybe push back or consider another solution’. So yes, your maintenance team also needs to be aware of that. I know. So that leads me to the subject of your accessibility experts. And by that time it might be interesting, if you do that on a regular basis, it might be interesting for you to have an in-house expert. It can be a developer that you’ve trained or that trained over the years. It can be that you hire someone like Craft has done. They hired an accessibility engineer to be part of the team. Now that’s an important person. They’re going to have to be consulted on a regular, you know, by all your team members pretty much. | [Marie at the podium] |
| And these are kind of the key point at which it’s good to have them on board. So discuss the design ideas with the designer so they can flag accessibility issues before they’re even happening. Review the designs. During the technical spec, maybe have them review your third party tools that you want to see to assess them. During development. And I know that Craft is doing that well. Like Lupe is actually, so she’s got control over the… she needs to review the pull request, right? Okay. So that’s amazing. She’s got power. You know, you need, it’s an important person. You need management to give them autonomy and authority so that the rest of the team will rely on them and will actually actively consult them. And by the way, so I know that the fact that Lupe is involved in that development phase. You know we laughed when Brandon said, ‘Oh, we did an audit and we had 500 issues in our backlog’. Now the fact that Lupe is involved in at the development stage, that gives me a guarantee that that backlog is actually going to go down. And it’s not going to be reset at every release and is not going to pile up. So thank you guys. You’re amazing. So yeah, you might want your specialist to perform repairs, or brief the rest of the team, train people who are entering content, and as I mentioned be there for maintenance. | [Top (first) row:] Planning [now in red], Project management [Second row, now in red and with person icon:] Design/UX [Third row, now in red and with person icon:] Technical spec [Fourth row, now in red and with person icon:] Development [Fifth row, now in red and with person icon:] QA, Repairs [Sixth row, now in red and with person icon:] Content entry [Seventh row, now in red and with person icon:] Maintenance |
| Now these conversations, they take time. The outcome of it are further actions. So, yay, project managers also need to be aware of accessibility, because they need to factor it in. They might have to sell it to the client: ‘Oh, this is where your money is going. We had all those conversations and all those repairs…’ So I’m afraid that’s what we’re aiming for. It’s important that, yeah, all your team is aware of accessibility in that they have a certain amount of knowledge. | [Marie at the podium] |
| So, when everybody needs to be on board and aware, that’s what we call a culture change. And I think that as an industry and as a society, actually, we’re somewhere in the middle of it. So it will take time, but that’s fine. | [All rows now in red and with an accessibility icon] [Top (first) row:] Planning, Project management [Second row:] Design [Third row:] Technical spec [Fourth row:] Development [Fifth row:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| Yes, so, what I observe a lot, so that’s, that’s what, sorry, that’s what we’re aiming for. | [Marie at the podium] |
| What I see a lot when I look at accessibility statements of CMS vendors or, or other software developers, is their accessibility strategy solely focuses on repairs. The gist of it is towards the end of a release, or development, we’ve got accessibility people checking our work or members of the community. They raise GitHub issues and then we look at these issues and repair to the best of our abilities as long as it doesn’t upset our release cycle, you know, our release schedule too much. Unfortunately, when you do that, you don’t have a guarantee that accessibility is going to gradually improve. It can regress and that’s an issue. | [Top (first) row:] Planning, Project management [Second row:] Design [Third row:] Technical spec [Fourth row:] Development [Fifth row, in red and with accessibility icons:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| So you need to shift left. Not sure whether you’ve come across that phrase before? So that means you need to bring accessibility as early as possible into your process to avoid any issues. | [Top (first) row:] Planning, Project management [Second row:] Design [Third row:] Technical spec [Fourth row:] Development [Fifth row, in red and with accessibility icons, and now with “Shift left” and a left-pointing arrow:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| So just a quick recap on what your staff needs. They will all need awareness and a bit of training, but not everybody in your team needs to be an accessibility expert. You can have just one, two, or an external consultant. But yeah, each will need a certain level – developers probably more than, and designers probably more than the rest of the team. They need tools and what I mean by that is really simple, quick tools for self-assessments – because if you’re auditing it’s best if you leave it to an external agency anyway. So the Axe DevTool for devs; contrast checkers for, er, designers; content authors might want to have like a language level tester, something like that. And they need an expert on board or, you know, a consultant that they can ask questions to and refer to. | Staff needs:
|
| Again, the link to that, that’s a resource that Nicki at Studio 24 who’s an accessibility specialist, pointed me to. abc.net.au has written that PDF guide about breaking down the team by role and what they should know about accessibility. | [Screenshot of the front cover of “Accessibility. Tips for teams”] Visit https://abc.net.au/accessibility |
| Quite randomly, the Department of Work and Pension of the UK Government has got very good documentation on that as well. So go and check them out. It’s going to be in the list of resources that, you know, I’m going to send you. | [Screenshot of the Department for Work and Pensions Accessibility Manual – Guidance for your job role] https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role] |
| So yes, that’s what we’re aiming for depending on your operation, your size, your requirement. You might get there, you know, but if you think when you get out of here you’ll start slowly building up towards that process and you know what you’re aiming for, I’ll have done my job here. There you go. | [All rows now in red and with an accessibility icon] [Top (first) row:] Planning, Project management [Second row:] Design [Third row:] Technical spec [Fourth row:] Development [Fifth row:] QA, Repairs [Sixth row:] Content entry [Seventh row:] Maintenance |
| Now, we’ve got a few things that we hope will help and that came out of the W3C website redesign. Because they’re basically banks of HTML, CSS, JavaScript patterns that we’ve come up with for that project and they’ve been audited for accessibility and they’re publicly available. | Resources to kickstart your journey into accessibility |
| Starting with the W3C design system. We worked on one of their websites, but they’ve got a series of other applications that they could not bring into the headless front-end app. So we needed a design system for everybody to use the same components throughout their assets, um, their online presence. | W3C design system
|
| You can use it for learning by observing or for your personal projects if you don’t, you know, if it doesn’t matter for you to have the W3C branding and colours. And everything in there has been fully audited for accessibility. | [Marie at the podium] |
| So that’s just one screenshot of one component. It really goes from the fundamentals of styles, layouts, up to full page templates. And you always have a bit of an explanation, an example, and then the code that you can copy and paste. [Marie swallowing] We’ll see how far I go, by the end. | [Screenshot of a page in the W3C design system, about collapsible containers, showing explanatory text, an example and a code snippet.] https://design-system.w3.org/ |
| I’m saying, so I’m focusing on accessibility here, but there’s a lot more that went into every one of these components. Because working with W3C, like, every component that we were producing, we were, we had to justify all our approach. So we actually had to present our CSS approach – we never do that with a client. And in the audience there was actually one of the co-founders, Bert Boss, one of co-creators of CSS. You know, Imposter Syndrome was high! [Audience laughter] I didn’t do that, that was Nicki, but we spent a lot of time debating because we would receive feedback from individuals from the W3C and each of them is specialised in one area. So we’d receive feedback on performance, mark up readability, internationalisation and we had to, kind of, every time consider all these aspects, prioritise them, and then convert that into actual HTML things. And many people ask us ‘Why didn’t W3C do it themselves? They’ve got the experts in-house.’ But actually, first of all, they don’t have design and usability expertise. It’s purely, like, technical. But also, you know, we really brought value and it took us time to understand that was our role. Collating all that expertise and then organising it and building according to that. So we really honed our best practices. Like, we settled loads of old debates about how to do things well in HTML and CSS and JS. | [Marie at the podium] |
| Yes, that design system is available. Again, all the repos of W3C, they’re public, you can go and fork it and comment. It doubles up as a templates bundle for a Symfony application, but that’s because we set up a headless architecture. And yeah, so they’re Twig templates, so you can’t just copy and paste them and use them into your Craft websites because it’s not made for that. But it’s still Twig templates that you can still, like copy paste or observe, if you’re interested. | [Screenshot of the W3C GitHub repository for the “W3C website templates bundle”] https://github.com/w3c/w3c-website-templates-bundle |
| And then there’s Amplify. So that’s our own, Studio 24’s, front-end starter kit. | [Marie at the podium] |
| We insist that it’s a starter kit, it’s not a framework. Please, it’s not a framework. Frameworks are usually made for quick prototyping and, you know, when you use frameworks you, kind of, quickly rely on the existing components on the framework and then you kind of need to override a lot of their rules to to make it work. This is really a front-end starter kit. So you use it as your boilerplate, not to reinvent the wheel, and you’re encouraged to edit it and then build up on it, like, amplify! You can use it for your learning and in commercial projects. So we’ve started using it ourselves in commercial projects. Most components have been audited for accessibility for the good reason that they come out of the W3C design system. | Amplify
|
| What happened is that we did all that work, all those debates about best practices, and then realised, ‘Oh, we don’t want to go back to our old ways. We want to keep that and carry it through all our projects now.’ So, Nicki, our front-end specialist, and Isaac, one of our designers, they sat down, looked at the W3C design system, stripped out the branding, stripped out all the components that were too project specific, and they just kept all the good things for everyone. | [Marie at the podium] |
| So that’s the screenshot of the home page of Amplify. Again, it goes from the fundamentals of typography, layout, up to components. You can see at the top right, there’s a section about design handover and standards, ‘cos it’s really aimed to be used from the design phase for the designer and the developer to work together. And if you go there, there’s actually a link to a Figma file for your designers with all the checklists of what they need to pay attention to and templates for these components. So, yeah, so that you can easily transition from design to dev. | [Homepage of the Amplify website] https://amplify.studio24.net/amplify/ |
| An example of the kind of thinking that went into that. Er, Nicki loves cats, ha ha! So that’s one of the components: a simple card. You know, it’s a very recurring pattern on our websites. | [Screenshot from Amplify showing a simple card component. The image in the card is of a cat.] |
| And that’s the markup for it. So you can see that the image comes last despite the fact that it’s coming first in the component. It doesn’t have an alt text because it’s purely decorative. And the reason for that is that if you think about it, and strip out the visual element, what you’re really after in a card is the title and then the description and the link to the resource. Semantically it’s better to write it that way and then with JavaScript… oh, sorry, not with JavaScript, sorry, with CSS. We flip, you know, we’re using Flex, we flip the order. | [Screenshot showing the markup for a simple card component in Amplify] |
| And, yeah, no, not with JavaScript – we actually have a very strict policy of progressive enhancement. So everything we write works without JavaScript first and then you layer it with CSS, and then you add some JavaScript to enhance it. Okay, there was one of the members of W3C actually uses a very old browser with JS turned off systematically. We got a lot of feedback from him about navigation and that kind of thing, so. [Murmuring in the audience] But in case you’ve got that in your audience… | [Marie at the podium] |
| the repo for Amplify is public, is open source. So go out and please use it, issue pull requests. We’ll see if we’ve got time to actually deal with them, but if you’ve got any issues or anything, please do send them across. | [Screenshot of the Studio24 GitHub repository for Amplify] https://github.com/studio24/amplify |
| Just if you’re interested, everything is public, everything that we’ve done with W3C is public. So if you want to see how we’ve used Craft as a headless CMS, if you want to see the Symfony front-end app and how we’ve pulled the data from Craft and, you know, reorganised them etc. it’s all there for you to see. | Other resources
|
| So, what can we take away from this adventure with W3C? Building and maintaining an accessible website is a process, okay? It’s a process, I insist. I will not insist enough, aha, about it. And Craft, thanks to slowly adopting these processes, is well on its way to WCAG compliance. That’s amazing! That’s a massive selling point for some of us, you know, who have clients in the public sector or charities that are big on accessibility. And, I know, personally, I think it’s a really good thing. It’s unique, clearly. | Takeaways
[Three large red arrows and scribbled circles emphasise the word: process]
|
| And then, yes, please go ahead and use the W3C design system and Amplify, and tell us what you think. | [Marie at the podium] |
| And, you know, if we can help you have ready-made accessible patterns that’s amazing. | Takeaways
|
| If you do any project with Amplify just reach out, we’d like to know. You can reach us on Twitter or [email protected]. | Show off you projects built on Amplify Twitter: @studio24.net Email: [email protected] |
| I’m repeating myself, but yes, that’s where you go. And I’ll post it in the Discord channel to find all the resources listed and mentioned in this talk. | List of resources mentioned: https://studio24.net/blog/dotall2022 |
| And that leads me to, thank you! Thank you very much. You can also email me. I’m the only Marie Manandise on LinkedIn so you can just look me up and, and hook up. I’m not on Twitter or anything. | Thank you! Marie Manandise, Studio 24 |
| Uh, yeah, and for further questions I’ll be at the bar. Thank you. [Audience laughter and clapping] Host: All right, thank you Marie! | [Marie at the podium] .all [Dot All] Marie Manandise Accessibility Takeaways from the W3C Redesign
|
| [Instrumental keyboard music] | Thank you to our sponsors:
|
| [Instrumental keyboard music] | [Dot All Conference logo and a photo of New York’s Brooklyn Bridge and skyline] |