 Thank you for having me here at Drupal South Sydney 2024, I'm sorry I couldn't make it in person. Today I'm talking about the history of web accessibility. So the history of web accessibility. The first thing I would like to do is acknowledge the Gadigal people of the Eora Nation as the traditional owners of the land that is basically being used for the Drupal South Sydney conference. And I just want to talk a little bit about my team. We're a little bit smaller. COVID had our way with it with us. But this was back in 2018 when about two thirds of us went to CSUN. And one of the things that I specifically wanted to do when I started with Accessibility Oz was to basically provide employment for people with disabilities as well as making the world a more accessible place. And so you can see us, we don't necessarily look like we have disabilities. But at any one time I've had a staff with at least 60% of people with disabilities. I've had people with dyslexia, moderate vision impairment, epilepsy, migraines, severe vision impairment, physical impairment, post traumatic stress disorder, Crohn's disease, multiple sclerosis, cerebral palsy and long COVID. The last one is something that I suffer from myself. I caught COVID at CSUN in 2023 and unfortunately I'm still recovering. And the one thing to remember when it comes to accessibility is it's not just about vision impairments. A lot of people think accessibility is only about people who are blind using a screen reader and that's absolutely not the case. In fact, the largest group of people with disabilities who use the web are people with cognitive disabilities because they're the largest group of people with disabilities. A little about me, why you should listen to me and why I'm talking about the history of accessibility. I started in accessibility in 1998. I worked on the very first accessible website in Australia which was the Vision Australia Foundation closely followed by Disability Online. And I created Australia's first automated accessibility testing tool called Purplecop. I was an invited expert to the W3C Web Content Accessibility Guidelines version 2 working group. I spent six years with them working on WCAG 2 and I also worked on the Melbourne 2006 Commonwealth Games. In fact, we've actually been involved in all Commonwealth Games since then including the not happening Victoria 2026 Commonwealth Games which took us all by surprise. I spent five years managing usability and accessibility services at Monash University and then I left in 2011 to fire found accessibility OZ. We released OZ player in 2012 which is our accessible video player OZART, our automated accessibility testing tool in 2014. I spoke at the United Nations on the importance of web accessibility in 2015, nominated for Australian of the Year in 2016 and from 2018 to now I've been chairing the ICT mobile site and native app testing committee talking about mobile accessibility guidelines and I won the inaugural Australian Access Award accessibility person of the year in 2019. So that's why I can talk about the history of accessibility. So the very first thing that happened was the first HTML specification was released if you want to talk about web accessibility. It was published by Tim Berners-Lee who is known as the founder of the web also the founder of the W3C. It supported only text and it had 18 tags. The world was a lot easier to make accessible back then and in 1995 what ended up happening is the unified website accessibility guidelines were released. Now these were compiled by Greg van der Heiden who has been in the industry a very long time, was developed by people in the accessibility industry with no input or direction from policy bodies and it actually came from a discussion between Tim Berners-Lee and Mike Passiello and Mike Passiello is a titan in the accessibility industry. Tim Berners-Lee went to a pre-conference workshop run by Mike at a WWW conference talking about web accessibility and because he went to that pre-conference workshop he actually mentioned disability access in his keynote and so the first version of the unified website accessibility guidelines was released in 1995 and version 8 was released in 1998 and was the starting point for WCAG 1 so they managed to go through 3 versions sorry 8 versions in 3 years pretty impressive. The next big thing is 1995 HTML2 was released which included support for things like images and 1995 a programming language called Mokka was released. It was written in 10 days by Brendan Eich and then renamed to LiveScript and then to JavaScript in May 1995 so JavaScript as we know and love it was actually written in 10 days. 1995 the first Internet Explorer was released before that we used things like Netscape and Opera and that was really the beginning of the end of accessibility I joke but yes Internet Explorer did make things difficult for the accessibility industry for its lack support of tags and misrendering of a lot of content. In 1997 the web accessibility initiative was created which is a part of the W3C and in 1997 HTML3 was released and it was the first HTML specification to be published as a W3C recommendation and they took over HTML from there. December 1997 HTML4 was released and it had 3 variations and this is where it got really complicated they had the strict variation in which deprecated elements are forbidden and if you actually used a deprecated element often the page itself wouldn't render at all transitional in which deprecated elements are allowed and frame set in which mostly frame related elements are allowed and it was phasing out visual markup features in favor of things like CSS so CSS was fairly new back then too. 1998 section 508 was released in the US and section 508 is really important because it really put accessibility on the map from a policy perspective. Bill Clinton signed the work force investment act into law which is basically section 508 which required accessibility for electronic and IT systems for all federal purchases and the W3C as a result started working on WCAG 1. So a year later WCAG 1 was released which was really quick. It had 14 guidelines and 65 checkpoints and it was often seen to be too complex which is hilarious and it was not technology independent it referenced things like client side and server side image maps it didn't allow click here links etc. So I'm going to read you the priority one checkpoints which are basically the level A checkpoints of WCAG 1 so you can understand kind of what we were dealing with back then. So in general priority one 1.1 provide a text equivalent for every non text element e.g. via alt, long desk or in element content. This includes images, graphical representations of text including symbols, image map regions, animations e.g. animated gifs, applets and programmatic objects, ASCII art, oh remember ASCII art, frames, scripts, images, sorry images used as list bullets, spaces, graphical buttons, sounds, played with or without user interaction, standalone audio files, audio tracks of video and video. So that was 1.1 it's the most complex of all of them. 2.1 ensure that all information conveyed with color is also available without color for example from context or markup. 4.1 clearly identify changes in the natural language of a document's text and any text equivalents e.g. captions. 6.1 organize documents so that they may be read without style sheets for example when an HTML document is rendered without associated style sheets it must still be possible to read the document. 6.2 ensure that equivalents for dynamic content are updated when the dynamic content changes. 7.1 until user agents allow users to control flickering avoid causing the screen to flicker. 14.1 use the clearest and simplest language appropriate for a site's content. So that was the general checkpoints and then you have the and if you use images and image maps checkpoints. 1.2 provide redundant text links for each active region of a server side image map and 9.1 provide client side image maps instead of server side image maps except where the regions cannot be defined with an available geometric shape and if you use tables 5.1 for data tables identify row and column headers 5.2 for data tables that have two or more logical levels of row or column headers use markup to associate data cells and header cells and if you use frames title each frame to facilitate frame identification and navigation and if you use applets and scripts ensure that pages are usable when scripts, applets or other programmatic objects are turned off or not supported if this is not possible provide equivalent information on an alternative accessible page and if you use multimedia 1.3 until user agents can automatically read aloud the text equivalent of a visual track provide an audit to read description of the important information of the visual track of a multimedia presentation and 1.4 for any time paced multimedia presentation e.g a movie or animation synchronize equivalent alternatives e.g captions or audit tree descriptions of the visual track with the presentation and the very interesting last checkpoint in priority one level A and if all else fails 11.4 if after best efforts you cannot create an accessible page provide a link to an alternative page that uses W3C technologies is accessible has equivalent information or functionality and is updated as often as the inaccessible original page and that's where things get really interesting so this is why we often see things that seem to be okay like separate sites for people with disabilities and that's where this comes from this WCAG 1 checkpoint and it's actually not allowed in WCAG 2 so that's something that you know you can sort of see how it's progressed in that way but it's definitely not something that you should be implementing now and 2001 VPAT 1.0 was released which was developed in partnership with the US government general services administration and information technology industry council so that's a US thing and one of the reasons why that was created was because a year before in the year 2000 there was the first web accessibility litigation and it occurred in Australia Bruce McGuire who is a Sydney man and is vision impaired wanted to buy tickets to see the Sydney Olympic Games and so he couldn't buy tickets and he complained to SoCog which is the Sydney operation operating committee of the Olympic Games they ignored him so he went to the Human Rights and Equal Opportunity Commission which is now called the Australian Human Rights Commission and they talked to SoCog and SoCog ignored them so it ended up in court so the case itself was based on three sorry two major issues one they used JavaScript for navigation and back then screen readers couldn't interpret JavaScript so you needed to have a kind of backup alternative if you ever use JavaScript and instead of having coded tables of results they had screenshots of tables so basically SoCog in court argued that it would cost 16 million dollars to make the site accessible the judge finds them $20,000 because he deemed it would cost would have cost $10,000 to make the site accessible and he doubled that figure however he awarded attorney fees to McGuire and Herriock and they were in excess of half a million dollars so SoCog was up for the 20,000 but also up for the half a million of attorneys fees for Herriock and also of course their own attorneys fees and they blew out experts from the US to talk about how difficult it would be to make the site accessible the interesting thing I was working in accessibility at that stage at a company called Sausage Software which was the very first WYSIWYG so what you see is what you get HTML editor and it hit the front page of every newspaper in Australia and around the same time a little bit related I joined the web content accessibility guidelines working group and we started working on WCAG 2. 2002 Firefox was first released which is a great browser and really made things a lot easier because really IE was running the show at that point and then we had the very weird situation of the WYSIWYG and the HTML text working group so in June 2004 the web hypertext application technology working group which is the WYSIWYG was formed in response to the slow development of web standards by the W3C so you might have noticed that back in 99 HTML4 was released however you know it's 2004 and there's still no HTML5 this is because the W3C was really looking at XHTML and XML which of course died a slow death but they basically this this group formed outside the W3C to work on HTML and this is something that as you can see happens quite a lot in accessibility you know the first accessibility guidelines were created outside of policy I'm working on a set of mobile guidelines at the moment outside of policy groups like the W3C and it's something that tends to happen when we feel that you know policy is not keeping up with the IT of accessibility so basically XHTML was too unforgiving in terms of error handling so if you wrote your XHTML a little bit incorrectly once again you just get a page that wouldn't render and I mean the whole point of the web is rendering pages so it was just something that was not particularly helpful so in 2006 the first public draft of WCAG 2 was released and it was quite controversial for a number of reasons the first reason was the testability requirement which they still require I actually wrote a list of and a list of part article called testability costs too much and basically the concept of testability is that eight out of ten accessibility specialists agree on the outcome so it's not about automated testing but you as you know you put you know ten accessibility specialists in a room you'll get ten different answers it's really hard for us all to agree and so that was kind of my argument with testability is that it's something that you just you just can't reach and so it made it was the reason why certain requirements that were in WCAG 1 were not included in WCAG 2 so for example the clear and simple checkpoint ensured that your content is clear and simple was relegated to level 3 which does not need to or AAA which does not need to meet testability requirements and as I like to say AAA is where success criterion go die so we were a number of people were quite unimpressed that the clear and simple checkpoint had been relegated to AAA and the reasoning was this testability and my argument was you know testability you know you couldn't meet it on whether an alt attribute was accurate you couldn't meet it on whether captions were 100% accurate etc so it was not something that you should you know decide as to whether a requirement should be in AA or AAA because the clear and simple checkpoint got moved to AAA Lisa Seaman lodged a formal objection of which about 35 to 40 accessibility specialists cosigned including myself and her formal objection was that WCAG 2 did not address the needs of people with cognitive disabilities as a result of that formal objection WCAG 2 was pulled from public release and basically the working group split in a little bit of a way now in the the guidelines that were finally released there is actually a section which says that WCAG 2 does not accurately or sufficiently make things accessible for people with cognitive disabilities so instead of actually changing WCAG 2 to improve things that people with cognitive disabilities may require they just added this clause that says hey WCAG 2 is not sufficient you need to do other things as well which is a bit unfortunate however before WCAG 2 was released as I said this WCAG version in 2006 was pulled from public release and a small group of accessibility specialists worked on something called the WCAG samurai rata and basically this was run by Joe Clark who was very big in accessibility at the time doesn't really work in accessibility now and he said instead of creating a WCAG 2 what we need to do is create a WCAG 1.1 and so basically he got together a group of anonymous accessibility specialists and they wrote a WCAG 1.1 which they called the WCAG samurai rata and he got a couple of accessibility specialists to present a third party review of the document and I was one of those specialists in terms of reviewing what we thought was good and what we thought was bad and if you do enough searching you can still find that on the web now WCAG 2 was published in 2008 and I published a blog post called why I'm still using WCAG 1 but you know after a year or two I did jump on the WCAG 2 bandwagon as they fleshed out the you know understanding the success criteria sections and things like that but it was very controversial now in between that time really interesting thing happened Apple released their iPhone and so it was the first real smartphone I mean I used Palm pilots and things like that which I thought were fantastic but you know I had to synchronize it with my computer through a cable when I got home and it was monochrome and even though when I was on the working group what we wanted to do was ensure that the WCAG 2 with the last web content accessibility guidelines we really tried to make some technology neutral which is why you've got some very generic language in WCAG 2 we really kind of wanted to make sure that whatever technology came along you could apply WCAG 2 however of course when the majority of WCAG 2 was written there was no iPhone there were no native apps and the kind of ways that we see people use the internet now through their smartphones we just had not conceived of and so really even though Apple released in 2007 it took a few years before native apps really keep you know started and so we had to really kind of missed that unfortunately and 2008 Watwood published their first public working draft which was then closely followed by the W3C publishing HTML5 so there's real controversy between the two basically eventually HTML5 took over. 2008 WCAG 2 was published very busy first 10 years and 2008 the W3C begins work on this thing called ARIA which is accessible rich internet applications so ARIA is not a true programming language but a set of attributes that you can add to HTML elements to increase their accessibility you know these attributes communicate roles state and property to assistive technologies via accessibility APIs found in modern browsers and this communication happens through the accessibility tree however it's really important for people using ARIA to know that if there are ways that you can use HTML to do the same things then you need to use HTML because HTML has accessibility built in and HTML is available to everyone not just assistive technologies so for example your old attribute on your image is the standard HTML way of providing an alternative text of the image you don't want to use ARIA described by because ARIA described by is only available to people who use assistive technologies and you might say oh but only assistive technologies need to use the old attributes and that's not the case there might be some people that want to browse with images disabled due to say security concerns and they're not going to be able to access the ARIA described by but they are going to be able to access the old attribute so that's why it's really really really important to use HTML when you can and not use ARIA in 2008 chrome was first released chrome I love chrome before chrome I was using opera because opera allowed you to have multiple tabs open I actually released a newsletter had about 5000 people that I sent it to from about 2004 to 2006 I released it monthly and it was like the latest on accessibility and in order to do that I would go through all the links that I've been sent to open up all in the browsers I'd read through them and decide which ones were necessary to be included and of course if you open 40, 50 IE versions that's going to crash your computer but opera you can have multiple tabs and when chrome first came out it had tabs as well and I switched over another interesting thing that happened in 2008 is target in the US so was sued by the national federation for the blind now target argued that there was a lack of alt text that online purchases required a mouse the inaccessible image maps I mean seriously 2008 headings missing and basically they formed a class action lawsuit they had been complaining since 2005 and had just been given the run around which is very common when it comes to accessibility complaints and target basically argued that because they the website was not connected to a single physical location because it's under the accommodations acts that you sue people in the US and they argued therefore it doesn't need to be accessible the judge found that that was not the case and they ended up settling out of court now they settled for damages of six million dollars and they also had to pay NFB's legal fees which were an excessive three and a half million dollars and they also had to get NFB to test their website for a very hefty fee every year afterwards so they they're looking at about 10 million dollars which is a huge amount of money for a an organization for any organization and so basically that really turned people on to accessibility again a little bit like how the accessibility litigation in 2000 did in Australia in 2009 the W3C went XHTML we have decided that that's not a great idea and decided that they would continue HTML5 only and then the most important thing happened which was 2011 accessibility OZ was founded and although 2011 accessibility OZ was found another small thing happened that year which was Twitter Twitter who would have thought it released the first CSS framework bootstrap and basically bootstrap as a CSS framework was an open source project in 2002 bootstrap two was released with a 12 column responsive bridge layout which is why you see that everywhere alongside many other new features and in 2013 bootstrap three was released which had redesigned components and had a mobile first design philosophy that's over a decade ago and this is why it's really interesting once again that if you are outside of policy organizations you can actually get things released pretty quickly and that you have organizations like Twitter seems really strange you know moving accessibility needle 2012 Netflix was sued by the National Association for the Deaf and this is the first time once again in the US that a company was was sued that didn't have a public location and so Netflix argued quite a lot of things as to why they didn't need to provide captions to their content even when there was captions so they firstly argued that they didn't have to because there was a they weren't a public location and then they argued that if they provided captions it would be a copyright violation so the judge kind of said that's not a very good defense in judging words and he required that Netflix provide captions within 24 months and awarded the two complainants $795,000 in damages and so what's interesting about that is in 2015 a TV show called Daredevil was released which is about a blind superhero and you think perhaps blind people would like to watch a TV show about a blind superhero and it was released without audio descriptions now captions are for people who are deaf audio descriptions are for people who are blind or vision impaired and there's a real difference between how people or how policy deals with captions versus audio descriptions so in the US everything needs to be captions you need to provide captions for all your content TV cable everything whereas you only need to provide 20 hours of audio described content for per say cable company or something like that 20 hours a week which is very very peculiar and this you saw that as well in WCAG one so WCAG one required sorry WCAG two WCAG two required that captions are provided at the bottom level at level A and only required audio descriptions at the double A level so it is something that is peculiar about the accessibility industry that audio descriptions are not seen on par with captions so in 2015 this TV show was released in its entirety about a blind superhero without audio descriptions and there was a bit kerfuffle in the accessibility industry and Netflix actually provided audio descriptions for Daredevil within three days of its release and the audio descriptions are absolutely excellent so if you ever want to see here really good audio descriptions then have a look at Daredevil and it's absolutely impossible to get audio descriptions for that much content done in three days so there is a small minority of the accessibility industry who thinks that maybe it was a bit of a stunt on Netflix's part to kind of get a bit of publicity they say there's no such thing as bad publicity and then in 2012 WCAG and the W3C decide to cooperate so as few years there are two in throwing and so the W3C took over the HTML5 specification and decided to focus on a single definitive standard HTML and it was considered as a snapshot of Watwig so the Watwig does actually continue its work with HTML and is seen as a living standard so Watwig actually talks about things that browsers might start to support but aren't actually included in the snapshot version of HTML5 so that's how the two are different. In 2013 in May at a JavaScript conference in the US a new library called React was introduced it was created by Jordan Walk who's a software engineer working for Facebook once again strange companies to be pushing the accessibility envelope so basically our existing CSS frameworks even such as Bootstrap also built things like versions for React and today React is the most popular JavaScript technology unfortunately it's not very accessible so there is that problem. A year later Coles was sued in Australia and so this is an interesting story so basically a woman vision impaired again in Sydney again Chazelle Monage she had been working for several years with Coles to make their systems accessible and in early 2014 she could finally do some online grocery shopping and get it delivered to her door and then mid 2014 Coles released a new app and a new website which was not accessible and Chazelle was understandably annoyed so she went to the she complained of which Coles did nothing so she went to the Australian Human Rights Commissioner who had been assisting her with talking to Coles but the coalition government had at that point retrenched or laid off the disability discrimination commissioner from the Australian Human Rights Commission now 47% of all complaints the Australian Human Rights Commission receive are regarding disability and they have a lot of commissions like aged care commissioners gender commissioners racial equality commissioners sexuality commissioners etc and you know it's really kind of strange to retrench the commissioner that is responsible for the most number of complaints but that's what they did back in 2014 so Chazelle had no other option than to actually sue Coles so she did now they settled out of court for an undisclosed sum and Coles then went on to work very hard to make their content accessible but once again it was another thing that basically lit a fire when it came to accessibility. Another thing that happened in 2014 was EN 301549 I mean seriously they really need to get a better name and it was about the public procurement of ICT products and services in the EU so this is basically the section 508 of Europe except it also includes a whole lot of other things as well and when it says hey you need to make your website accessible clearly I'm paraphrasing it references WCAG 2 so it's basically now at a stage where WCAG 2 is seen to be the standard across the world. In 2014 WAIA 1.1 was released sorry 1.0 was released once again takes a long time to do anything in the W3C and at the same time the BBC released their mobile accessibility guidelines and so basically the one thing about these guidelines is the first mobile accessibility guidelines to be released is that they merged the native app and mobile site requirements so you never really knew whether it was something you needed to apply to a native app only or to a mobile site but these were seen as the de facto mobile accessibility guidelines for quite some time until about 2019-2020 the BBC came out and said we never expected anyone to actually use these guidelines we just released them you know so people would see what it is that we follow and you should really be considering other things you know like e-commerce that aren't covered by these guidelines but for many years the BBC mobile accessibility guidelines were watched people followed. The same year HTML5 was released and it was basically a very concerted effort by the W3C HTML working group and it included things like audio and video tags and made things like audio and video much more accessible. The same year WAIA 1.1 was released and you also got the VPAT 2.0 in the US and then in 2008, that's 18, WCAG 2.1 was released so it did address issues around the requirements of people with cognitive disabilities and low vision because they were left out of WCAG 2 however there was one thing that a number of mobile accessibility guidelines agreed on that weren't really addressed properly by WCAG 2.1 so by 2018 all the big accessibility companies, accessibility OZ included had their own mobile accessibility guidelines and one of the things that we all agreed on was that touch target sizes were needed to be a sufficient you know largest size and so that requirement was in WCAG 2.1 however it was relegated to AAA and as I said AAA is where success criteria and go to die and so that was something that the industry itself was fairly unimpressed about something that we all thought was really important that had just kind of been we felt ignored by the W3C and so why do we need this WCAG 2 thing and why did I go on to work on mobile accessibility guidelines so before we talk about WCAG 2.1 we need to talk about WCAG 2 so WCAG 2 success criteria are applicable to mobile so mobile sites or native apps or whatever however not all aspects of mobile accessibility are specifically covered by WCAG 2 we really tried but we didn't make it particularly we didn't make it perfectly technology neutral so for example although WCAG 2 requires sites to be accessible to the keyboard user it does not specify that it should also be accessible to the touchscreen user so as a result and because things were moving very slowly with WCAG 2.1 in 2018 we well 2017 we formed a group called the ICT mobile site and native app testing methodology subcommittee and we did this because in 2017 at the ICT accessibility testing symposium to the conference aimed at accessibility testers we all got together at the end and talked about what it is that the industry needed and basically what we required was a standard set of mobile accessibility guidelines because you got different things if you went to different companies so we knew that WCAG 2.1 would be released at some point so we thought this was a short-term issue we thought WCAG 2.1 would address all our requirements we were wrong and so we knew we just wanted to make sure until that happened we were all working off the same kind of guidebook so what we did is we amalgamated everyone's mobile testing guidelines and put them into a nice you know pretty order and we released them in 2018 and around the same time that WCAG 2.1 was released so WCAG 2.1 great it did build on WCAG 2 address more criteria related to touch screens such as pointer gestures sensors small screen devices however the accessibility industry really didn't feel like it covered all the user needs related to mobile accessibility of course touch targets sizes being the largest one so we reformed the committee and the second ICT mobile site and native app testing methodology was released in early 2020 and so that was something that you can still get it's on the accessibility OS website we're thinking of reforming the committee to write a new version we did kind of get you know waylaid by COVID but that is something that we do as a company follow and a lot of the large accessibility companies were involved in their development in that development as well in 2020 VPAT 2.4 was also released which incorporated WCAG 2.1 and then of course you know the end what happened in 2020 nothing happened after in March 2020 nothing happened after March 2020 basically COVID really threw a spanner in everyone's works there was a real belief that it would be you know a new age of accessibility in terms of everyone having to go online you know people ran out of money and accessibility once again was the thing that dropped off people's lists unfortunately uh basically in April 2022 WCAG 2.2 was released actually hold on a second no it wasn't April 2022 was September 2022 no it was November 2022 no February 23 no April 23 no June 23 these are all the times that the W3C said WCAG 2.2 would be released uh June 2023 way aria 1.2 was released which was great uh October WCAG 2.2 release 23 which is the case which is great um and it did have a few additional things that did improve accessibility so that is something that we are happy about however there were some things that we were not happy about let's start about with the things that we were happy about so touch target sizes were there was a new requirement added to AA which required touch target sizes a little bit smaller than the version in AAA but we all counted that as a win another thing that was included was dragging movements which was something that was in the ICT accessibility testing symposium mobile site and native app accessibility guidelines got to be a shorter way of saying that um so we were happy to see that included in WCAG 2.2 however the big one was uh success criterion for 0.1.1 passing was removed now what is passing a lot of people have no idea what passing is so the success criterion reads in content implemented using markup languages elements have complete start and end tags tags tags tags let me start again in content implemented using markup languages elements have complete start and end tags elements are nested according to their specifications elements do not contain duplicate attributes and any ids are unique except where the specifications allow these features how on earth are you supposed to test this like go through and look at every single tag open tag go does it have an end tag there is an easy way to do this which is called validation so HTML validation and it was a mainstay of WCAG 1 and it was a really easy way to determine if something wasn't accessible you throw it through the validator the validator spits out all these errors you go hey this site is not accessible however because a whole lot of uh companies were creating these WYSIWYG uh creating HTML through WYSIWYG editors they were finding that the HTML that was output was not passing the validation so in WCAG 1 you had a requirement for validation but in WCAG 2 you don't have a requirement for validation you have a requirement for passing now validation is one way to meet the passing requirement but it is not uh the only way so you could have people argue that their page doesn't validate but they still pass pass pass the passing requirement because who would ever know so this has meant that uh it was an easy way to check but it also meant that you could easily tell where the code was uh created properly so it could easily be interpreted by things like browsers or assistive technologies um and so they decided to remove it in WCAG 2.2 which has split the accessibility community a little uh there are people like myself who think that passing is important and there are the groups that think that it's an unnecessary test that needs to be performed so that's once again one of the many controversies of accessibility so thank you very much for coming to this talk I am sorry I can't be there in person I hope you learned something please don't um be offended if I did offend you I did not mean to it has been a very interesting 20 too many years 26 years in the accessibility industry um and it's something that I mean I love with a passion but uh the politics can be a little bit too much for me sometimes uh so once again thank you for listening to my Ted talk thank you for listening to my Drupal South talk and uh please reach out to me if you have any questions thank you