An Introduction to Accessible Web Content & Development

Just a brief introduction to what you’re going to get today, and then I’m going to hand over Usman who’s going to give that to you.

This is a taster of our web developer course. Our web developer course has got 11 modules in it. This is the first of those modules, the easiest one, and also the one where you don’t necessarily have to be a developer to really appreciate this because this is all about navigation, and navigation is absolutely something that coders need to get right, but it’s also something the content authors and designers need to get right as well. We thought this was a good way of giving you a taste of what our training is like without making it if you like too complicated and techie for you. So that’s what you’re going to get today.

I’m Jonathan. I’ve been working in this area for a very long time. I’m more on the strategy side, So if you’ve got questions you want to ask about strategy as we’re going through, I’m going to be the person answering them.

Right in the centre there and pride of place is Usman. He’s going to be the person delivering this training to you for about 45 minutes. Graham is another one of our developer trainers and he’s going to be the person answering any really technical questions that you might want to put in the chat as we go through because he knows answers miles better than I do.

So, without further ado, I’m going to stop sharing my screen and Usman is going to grab it and take you into the world of signposting content. Hey, Usman, take it away.

Thanks for that, Jonathan. Hi, everyone. I’m Usman Afzal. I’m going to be taking you through one of the modules from our developer course which is signposting content. So let’s take a look at the topics that are covered in this particular module. We’re going to begin by taking a look at the importance of using semantic HTML. We’re then going to be moving on to page titles. We’re then going to talk about headings and lists. Then after that, would be meaningful sequence, then landmarks, then specifying language, screen reader texts, and we’re going to end on the final topic which is the value to HTML.

Now accessibility begins by making use of semantic HTML elements correctly. So what are semantic HTML elements? Well, they are elements which have meaning within them. Examples of those we have headings, we have links, we have buttons, and form controls such as text areas, select, those dropdowns, the native drop-down that you have, checkboxes, radio buttons, etc. That’s just a few examples and there are many many more. Now along with these native elements having meaning behind them, they actually also come with additional benefits. Two benefits I’m going to be discussing.

The first one is they carry the necessary functionality within them and also the necessary accessibility features built within them. For example if we have a look at headings, what headings have a hierarchy and this information gives users an idea of what type of content that they’re looking at. The importance of the content, and it gives them the ability to find particular points of interest. When it comes to links and buttons, they are two different things which can be established. Links take users to a particular place. It could be a link to another website. It could be a link within the same website, or it could be an in-page link. Buttons on the other hand, they are used to trigger some form of functionality. They are two different things.

Now when it comes to form elements, we did cover that quite extensively in one of our modules in the developer course. But if I give a quick example, we have checkboxes and radio buttons. What we are able to do is identify when these particular input fields are checked or not checked. We also have labels which are used to describe what these input fields are actually for. So that’s native elements, which are very small, things which exist on a page.

We also have nowadays and have been for a number of years, we have components which are really a collection of these native elements to make something. Examples of those are components such as accordions, tab panels, carousels, and dropdowns. You can have quite like custom dropdowns, which can have features such as autocomplete. So they’re not native by themselves, but it’s a collection of elements to make a solution. We do cover that quite extensively towards the end of our developer course also. That’s a brief discussion on semantic elements, what they are, and components which are a collection of elements.

Now let’s discuss something that we firstly should be avoiding. That is making use of the title attribute to describe elements. Now historically, the title attribute was used in many places to provide a tool tip type of feature. You can see there’s an example here. We’ve got an image and when the user mouses over this image, then it auto appears with some helpful information. The problem is, however, in terms of accessibility, they are never the right answer. The reason for that is, firstly keyboard only users will never see them. Also, touch device users will never see them.

When it comes to screen reader users, many of them will not actually voice the title attribute, the texts within the title attribute. It can also lead to over announcing. If there was a screen reader which did recognise the types to attributes and announced the content. If you also had some texts which is within a link, it will then announce that twice, so it’s not a great experience.

Now when it comes to voice recognition software, for example Dragon Naturally Speaking, it would not notice the types of attributes. So here’s quite a few examples which are showing you that, that’s never the mechanism of providing really important information through that attribute. Now when it comes to the HTML5 spec, it’s also discouraged, it’s quite clear in there. There is that dependency effectively of having a pointing device. So it will only work if you have a cursor at that pointing device. You’re excluding keyboard only users and touch only users.

OK Let’s move on to page titles now. What are page titles? It’s not actually the heading that you see in the page content it’s actually something which is found in the browser tab. Now this was a snapshot of M&S bank taken a few years ago. So it’s no longer like this now, but it’s just used to show an example of the implications of not really handling our page titles correctly.

Now this snapshot, what we find is that in the page title, which is the tab itself, there is no mention of the page content in this case, which is insurance. What we should find is very similar to the way it’s conveyed within the main heading. The reason why what we find in this tab is banked at marksandspencer.com is because the actual title element itself has been left empty. Whenever you leave that element empty, the URL of that website then used in replacement for that. Which is never a helpful experience. You can imagine hearing a really long URL if it’s in this case back to marksandspencer.com slash insurance slash overview. But the users, what they should see instead, and hear in the case of a screen reader is insurance and Marks and Spencer bank.

When it comes to page titles, what should we come think about? Firstly, it’s the first announcement which is made by a screen reader when someone arrives on the page. It’s very important that it’s clear and it indicates exactly what the page content is about. It gives users a sense of orientation within your website so that they know that they are in the right place. Now a helpful way to manage your page titles is to create some form of pattern so that everyone within your organisation, whether they’re a content author or if they’re a developer, know how to structure your page titles.

A helpful way to go about it could be as follows. If you are a product based website, you could begin by using the name of the product. In this case, thermometer, and then the category that that product falls inside, in this case electronic products. Then you can end with actual company name, in this case, Robinson Health Care. We can use the same principle for any type of a website that you have. It doesn’t have the product base. It could be information-based and use a similar pattern.

Now, depending on the organisation and the type of business, your page titles could be handled in a number of different ways. If you have very small websites and you have a development team which are managing your page titles because they are changing them directly within the code base. Then it’ll be them that would have the responsibility to ensure that they are a unique, concise, and descriptive.

If you have a much more larger website and it’s managed by content authors via CMS. Then your content authors also need to understand that it’s very important that the page titles are concise, descriptive, and unique. So having a pattern just helps in that process.

Now, many websites are now built using frameworks, and there are many out there, and if we implement a website as a single-page application that actually has a different experience. There are no page refreshes occurring when you have single-page app. What that means is that views are being updated but there’s nothing actually triggering the screen reader to then announce the title.

The thing is however, although page titles are not being triggered because there’s no page refresh occurring, screen reader users can still access page title via some keystrokes. It’s very important that we still manage our page titles even though the views are changing and there’s no actual page refresh occurring. It’s very important that we still manage them.

Now back upon the topic of the title attribute, I mentioned earlier that it’s never the right solution in terms of providing information in an accessible way. However, there’s only one scenario where we would say it’s sensible to use it and it’s in the case of where to use an iframe. If for example, you are sharing a YouTube video and it’s suitable to make use of the title attribute within the iframe element to convey what that particular component or element is about. Say here for example, you’ve got a map being presented, so the title or the content that will be announced can be map of Parliament Square for the Google Maps image that you can see on the left. That is the only sensible use case really off the title attribute.

Now, let’s move onto headings. Now, headings are very important in both the digital world and also the physical world. So having a look at a picture which is taken within a Morrisons store, it’s a grocery store or supermarket where you can buy fresh fruit and vegetables and canned goods. What we find, whenever you visit a grocery store or supermarket, is you find these aisle numbers on top. Beside those aisle numbers you have signage labels which helps you as a customer to find particular products. In the case of aisle number 20, we have soup, hot snacks, canned vegetables, and baked beans.

These work very similarly to how headings work in the digital world. It gives you an indication of where things are located. You can imagine for the first time you enter a store and there’s no aisle numbers or there’s no labels or signage informing you of where any product is, you’ll have to walk through every aisle, so that will become quite frustrating. On this picture, we not only find signage informing you of where particular products are at a higher level but also at a more specific level. Below those signs you find more labels being presented, so you have canned fish, you have canned meat, so it’s giving you an indication of where you can find even more specific products within that aisle.

This works exactly in the same way on websites where we have a heading hierarchy, so you have high level headings, in this case, the ones beside 20, which is canned vegetables and baked beans, could be heading level 2s, and then you have your lower level headings which are canned meat, canned fish, it’s adding more specificity there.

Now, what we’re looking at here is a tool which is called Wave. What this tool does it exposes various different elements within a webpage. What we’re focusing on right now are the headings. So wave is informing us of which headings exist on the page, so it gives us a good indication of how many headings exist and what the actual heading hierarchy is. It’s a very good tool to use for testing and also just to get an idea of how a page is structured.

Now what we’re looking at here is what is called an element space. This is the feature that is within NVDA, which is a screen reader, a very really popular screen reader which can be downloaded for free. This feature of NVDA is very useful because what it does, it exposes the heading hierarchy on a particular page. What users can then do is use these headings as a navigation feature.

So if they find a point that they are interested in, they can then click on move to or go to move to, highlight that and move to that point because that is really how even a sighted user is scanning a page and looking at points of interests and then they go to be that content whenever, even if you were to go on a website for the first time, you tend not to scan from top to bottom, you’re just looking around what is interesting and you read from that point. The headings are used as a navigation feature for screen reader users. It’s really important that we include them and so it gets exposed in this heading hierarchy.

Now this is a website, it’s called OpenSea. You may be familiar with it, it’s very popular. It’s a marketplace of buying and selling NFTEs. What I did here was just to get a sense of how headings are structured here on this page because we can clearly see just by visually looking at a page if something should be a heading or not. Now, I use the WAVE tool on this webpage and we found that there were three headings that were at the bottom. We have marketplace, my account and resources, which is good. Now, when we use the elements list again, which is the feature within NVDA, we can see that the sighted users, they can clearly see other headings which can be seen. We have explore categories, we have art, we have gaming, memberships, stay in the loop, join the community but it’s not being presented in the elements list.

The reason for that is that these strings of text are being presented as headings but they’re not actually marked up as headings. So that’s the reason why we see marketplace, my account, and resources in the headings element list. You can see how it’s very important that we mark headings as headings and not style them as headings but not mark them up as headings.

OK now, best practice when it comes to headings and subheadings. You want to always aim for logical heading structure. A screen reader users would pick up on this. Typically, a single heading level 1 is appropriate on pages and it’s very similar, if not pretty much the same as what is within the page title. It doesn’t have to be exact, it should reflect what is being presented in the heading level 1. It’s absolutely fine to begin with a heading level 2 even because we do recommend you have a heading, say if you have a cookie banner, many websites have cookie banners due to legislation, so having a heading within there is very useful because if it’s something that users need to interact with and confirm whether they accept or decline, having a heading there is increasing the probability that they will find that message, a screen reader user.

So if I navigate using heading, I’ll find it if I navigate using links or buttons I’ll find it, so you’re adding just increasing the probability of them interacting with an important feature like a cookie banner. So a heading level 2 could be the start of your page and then a heading level 1. But what’s important is that your subsequent headings then make sense. It needs to be following from a 1, to a 2, to a 3, etc, following a logical order.

Now, I mentioned in the previous slide to not style headings or style text to make it look as if it’s a heading but it’s not marked up as a heading. Similarly, we shouldn’t be using heading markup just to make something look bold. That’s also incorrect. Headings also contribute to SEO. So that’s another benefit. There’s many things involved in SEO but it’s just a contributing factor. You can also consider screen reader only headings to further explain structure of your pages. I’m going to describe that technique just in a few slides down but effectively just gives more health information if it’s required.

It’s not always necessary to use that technique for headings but it’s possible if you’d like to make use of that technique. Now an example of good heading hierarchy, you could begin by having a hidden heading for your main navigation. It’s not necessary but it could be possible to have that, can be helpful so when users reach that heading, they will hear the announcement main navigation. You then would have your main heading level 1 for your page. In this case, this is about harbour surgical gloves. Then your hierarchy would then look as follows. You have your heading level 2, in this case it’s main features, and then strength and flexibility is a subset of the main features, so it sits under the heading level 2. You could then have subsequent heading level 2s, in this case, it’s buying the correct gloves, and then a heading level 3s below that, which is about sizes available and the colours.

We’re showing an example here of potentially another hidden heading which could be used, in this case, we book further navigation and then after that we have heading level 3s, which are other surgical gloves and related products.

Let’s move on to lists now. We often find on many websites where things are presented in the way, things which are really lists or marked up as lists. They visibly look like they’re lists. You can see by phone, send a message write in the ranch. But they are making use of multiple divs. What you only find is a div, and in there is the link or the text or the icon. That’s not the right way of presenting a list within a mark up. Because if it is a list, it should be marked up as a list. Rather than using divs what we shouldn’t be using is a list item. Now in this case, it’s an unordered list. That is a UL. If it was an ordered list, it would be OL.

When you use an unordered list, it means that this is a list of items that could be in no particular order. The benefit of making use of the list is that when a screen reader uses that approaches this unordered list, it will let them know that firstly it’s a list and also how many items exist within the list. Why would that be a benefit? It will give the user the ability to then choose how they would like to interact with those list items. To say if there were 100 items in your list, it will be very different how they would interact with those list items as compared to if it was just a list of four. It gives them that information to make that choice.

Let’s move on to meaningful sequence now. It’s really important that we have content ordered logically, so the content needs to make sense. Assistive technologies are going to be interacting with the content in the order that it appears within the underlying HTML. A typical ordering for your page content could be as follows. You can have a banner, then the navigation, main content area, sidebars, and then your footer.

That’s very typical of how many websites are structured. Now the thing to be careful of is when we use techniques such as Flex and grids to influence the Visual Order of our page. Because what happens is visibly we can see it in a particular order, but the underlying HTML has it in a different order and the assistive technology is going to interact with it as it is within the underlying HTML. So these are things just to be aware of.

OK let’s talk about landmarks now. So what are landmarks? These are regions within our pages. And examples of those are; we have banner, navigation, main. What they do is they help define structure of our pages.

Screen reader users can use landmarks to also get to points of interests. So within the elements list that I’d shown in the previous slides, you can navigate using headings, links, buttons. They are very small elements on a page, but landmarks are greater areas. They’re regions where elements exist within them so they make up the landmark. It’s a greater area that users can get to if they are interested in that. So say, if they need to get to the main area, they could do that very easily. So it’s really important that we use these landmarks correctly. Otherwise, it can become quite confusing for screen reader users and we can give incorrect messages.

Now there are some landmarks which can be only be used once on the page. And there are others which can be used many times, and there are some landmarks which can be nested within other landmarks.

Now, when it comes to pages, all of our elements will or should be existing within at least one landmark. All of those various different elements I mentioned, they should be within a landmark. So the entire page is a document within there You have landmarks, within the landmarks you have elements. That’s how really we should be presenting our documents. Now many years ago, for those who remember, we used to structure our pages in the following way. We had many divs and we assigned rows to them. We use the row attribute with a value. We’d have row with the value of banner, row with the value of navigation, main content info, complimentary and search.

So this is how we would structure a page and convey what these things actually meant and the purpose and the meaning behind them. We’ve had HTML5 now for a number of years, which has really made things more easier. So rather than using the row attribute, we can use these HTML five elements which have meaning. We now have header, nav, main, footer, aside, and form. Now the only attribute or the value that we still need to use is search, because we don’t actually have a HTML5 element to search. That’s the only one that still saying definitely use. So with the row with a value of search, the others are no longer needed because they communicate effectively to screen leaders now.

Now, sectioning elements and landmarks. Now, whether or not a HTML5 sectioning elements becomes a landmark depends on a few rules. Now, it’s really important that we understand how these rules work as it can lead to confusing experiences for screen reader users. Now, we’ve got three elements which are always landmark. They are main, nav, and aside. Main never decide they are always landmarks.

The following HTML five elements are sometimes landmarks, and it depends on its positioning. They are header and footer. Header can exist on the top of your page, and it can exist at the bottom. If header and footer. Child elements of a particular landmark with another landmark, then they are considered landmarks with their descendants of sectioning elements, then they will no longer become landmarks. The header and footer, they shouldn’t be child elements. If they are of the following article, aside, and main, nav and section. If they are children of those elements, then they are no longer landmarks. Two elements, header and footer, can be landmarks and cannot be landmarks depending on its positioning.

Now, the following elements, section, and form, only are landmarks if they have an accessible label. How do we create an accessible label for those elements? Well, we make use of aria-label and aria-labeled by. Those two attributes will make section of the form a landmark. An example of that, say if you had a repayment calculator, you had a feature where there’s a mortgage calculator users can change values and it gives you a response. You can wrap that in a section, and that section could be labelled as repayment calculator. Then when a screen reader user approaches that section, when it receives focus, it will announce repayment calculator. We do actually cover, in a lot more detail, aria, and we do an introduction to aria and that’s another module within our developer course.

Now let’s take a look at an example of when landmarks have not been used on a website. So say if you just made a bare-bones, quite basic website and just made use of divs. There were no roles or patient or five elements being used. What you find is the elements list will have barely anything. This is again NVDA with the elements list showing what exists. Here we’ve only got banner navigation on content info. So we don’t even have the main area which is really important for users to get to. That is bad in terms of income mutation.

If you compare that to how it is after significant changes being made to the structure. What we find in the elements list is a lot more, there are many more landmarks being shown. So we have banner, we have navigation, we have main, complimentary content info and navigation. This is how we should be structuring our pages so that we are conveying all of that information to screen mediums. In this case, it’s being exposed within the landmarks radio button option in the elements list.

Let’s have a look at specifying language now.

You may be thinking, why do we need to specify the language? And this is in particular for the page as a whole, and the reason why we do this is so that the correct pronunciation is used for screen readers. So the screen reader user will have the correct pronunciation for that particular page. You can set the language of the page in the following way. On the HTML element, you have a lang attribute, and is given a value. That value could be a two-letter or a four-letter code. Now these values, where x is used to define the language code and needs to be a valid language code, and the XY this case is defined by a valid country code.

Now if you’d need a list of all of the value languages and regions which can be used. You can find that on the ‘i’ on a website in the language subtag registry. It’s just an image of how that looks. and it’ll give you all of the values which are valid. Now an example of how you can make use of, say, if you needed to present, English, we have HTML, then we have the lang attribute with a value of EN, which is for English, and then if you needed to have more specificity in this case, if you needed the country code. We’ve got GB here. This is great British English. If you wanted US, Then United States English, then you’d have EN-US. So that’s how you could differentiate between different versions of English.

OK so that’s at a page level. We can also specify language at a component level, and an example of that is say if we’ve got a language selector. We’ve got three languages here. We’ve got English, we’ve got Welch and you’ve got French in this language selector. Within the anchor element, we’ve got the lang attribute with a value. So you can see we’ve got lang EN, Lang CY and FR, Any content that exists within where the lang attribute is being used, we use the pronunciation of that lang. In the case of English, it will announce everything pronounced in English and if it was French it would say it in the French pronunciation.

Now screen reader text. So have a look at this. So what is screen reader text? You may be familiar with this or may not be. Effectively It’s a technique to provide additional information to screen reader users without making it invisible to sighted users so on screen. It’s really helpful to use this to clarify content or links wherever it’s required where something could not really make sense as it’s inefficient contexts for a screen reader user, and the good thing is this technique works for screen readers because it’s effectively just hidden texts that’s being presented.

Now, an example of where this could be useful. If you go back to that language selector. On this particular language selector, what we have is this black dot, which is to identify which language is currently selected. Currently, English is selected. The challenge, however, is when a screen reader approaches this, and when a screen reader, user is listening to the various language options, they will not be able to identify which language is selected.

So what we do is rather than saying there’s a black dot, that’s what a sighted user can see. We use screen reader text to convey this information. What we effectively just say it’s selected. So there’s a string of text in here in this span and it reads selected, it’s given a class of SRT, and SRT is just used as the screen reader text class name. We cannot see selected on the random component, but the screen reader user will hear selected. So in this case, English is selected. That is the context again, given that additional helpful information for a screen reader user.

Now when it comes to the implementation for a screen reader test. Effectively, it’s making use of the following properties. We’ve got border, clip, height, width, margin, padding, overflow, and position with those values. Now, this can be found online on many different websites. It could be on developing science, could be on StackOverflow. You don’t really have to take a snapshot. This is well-known in terms of how to use screen reader text. Now the effect of it is if we were to look at the HTML below, we’ve got a span with a class and the value here is accessible, hidden. It will render this text on the screen, but hidden sighted users. This is hidden from sighted users but accessible to screen readers.

Previously, quite a few years back, they used to be another technique of hiding texts, and it was using position, absolute top, the property top with a value of zero, and the left property with a value of negative 9,999, and this technique really only works when we’re dealing with left-right languages. So we would never recommend using that technique. The CSS that is on the left of the screen using border clip height, et cetera, is a much better robust solution over the previous method of implementing hidden text. Now things that we definitely never want to be using are the following properties. It’s displaying with a value of none, and visibility with a value of hidden, because they not only will be hidden from sighted users but also screen reader users will never see them. It’ll be ignored from screen readers too.

Let’s take a look at now signposting content for other use cases. If you’ve got an application, say in this case Toy Town online, and we’ve got three different products or accounts. Credit card, we have diamond premier and current account. We’re going to be focusing on the middle one, which is done in premier. We’re going to zoom in on that and we’re going to look at the HTML for specifically that area. Now we see the HTML is showing this is the list item because it’s a list of one item and there are two others. We also find in there the name of that particular product, or in this case, service is a diamond premiere and account. We then have the account number, we then have the so-called the current balance, and then the word or string of texts, current balance.

Now, we can improve this for screen reader users using that technique which is screen reader text. Let’s take a look at how this can be improved. Before or preceding the texts, diamond premier, if we use screen reader text. We’ve got simply a span with a class name, for our screen reader text, or in there we’ve got an account type. When the screen reader approaches this, it will announce the account type, diamond premier. Without that, it will just say diamond premier. So adding more information and more context about what this is actually representing. For the account number. Again, preceding the number will have a span with the class name referencing a screen reader text class name, and then they will have account number.

So we’ve announced an account number, then the value. If we had the same for the sort code. Let’s say it’s, sort code than the value, and the same for the current balance. So this is creating a much better experience for the screen reader user. It’s very similar to how a sighted user is experiencing that website or web application.

OK now let’s talk about validating HTML, which is the final thing now. This is the final topic. Now, when it comes to badly formed HTML, it can have an effect on assistive technologies and how they behave. So it’s really important that we follow the HTML5 spec, we validate what we are presenting within our browsers through various different tools, there are validation tools which can be used using the W3C validator online or what we definitely recommend is having validation as part of your workflow.

If your development team, as part of your continuous integration, you have these checks in place so that you’re not unnecessarily just putting badly nested HTML out there within your websites or web applications. So It’s very important that your nesting is correct, your starting and ending tags are where they should be. As I mentioned, always validate because the smallest of things can make huge challenges for different users. This is fundamentals in terms of just the baseline in terms of checks. Your accessibility will begin by semantic HTML, correctly marked up code, and then further on the manual checks will then come into play to ensure that your experiences are truly accessible. I hope that was helpful to everyone. It’s back to you, Jonathan.

That’s cool. Thank you, Usman. What a whistle stop tour of some of what you can get from our courses. I’m going to come back in a second with a few more questions that people have been asking, but I want to let Usman’s voice recover for a second before he answers any of the questions that people have sent through that I’ve picked out the key thing here and it was one of the things that actually came out in some of the chat was that it’s really important to make sure that when you are thinking about accessibility, you are thinking about it completely, if you like.

One of the examples given was a document that had headings in it, but they were all heading 1s. So somebody had got a little bit of information about accessibility, it’s good to do headings. But they hadn’t, if you like, heard all the way through to understand that actually you’re heading should be in a structure.

These are the things that make us quite sensitive and protective of our training because a lot of people get little bits of stuff in accessibility. But if you haven’t got, if you like the bigger picture, a lot of the time, you can get things wrong. So it’s one of the reasons why we’re particularly working out what is the best way of sharing some of the information in our training with you. But if you want the full accessibility for developers, there are some folks on the call as well who aren’t developers who are more in the content authoring space, or even understanding this sort of stuff from the design space it’s really important to understand that when you are designing a page, it’s good to be thinking about structuring of information on that page that the content authors will do and will be implemented in code potentially directly on the page by coders or through a content management system.

We had some very interesting conversations on the chat about some of that. So it is really important that if you like, all of those people come together to make good experiences on a page. Usman I’ve got a question here just in terms of, why is it important for designers and content authors to actually understand some of this HTML stuff that sometimes they struggle to understand. Why is that essential?

Well, it’s essential because of what we’re doing is we’re designing and you’re producing content for a document. This document is the webpage. All pages need some form of structure. The structure is given through the landmarks and the semantic HTML elements like I mentioned. So if you can grasp those topics around, everything has some sort of meaning behind it. If we introduce some texts on the screen, is this a heading? Is it paragraph? If it’s a heading, where does that fit within the actual page content itself? What is the page itself? What is this page about? There needs to be a primary heading and then you have your subsequent subheadings which fall below. So if you can understand that that thing you’re thinking of from a document perspective.

I am creating content or designing for a document, then I need to bear those things in mind. Then the developer will know exactly what they are creating. I can see that’s the heading, this is a side, this is the article, here’s the main area. If things are designed in a way which are really making it difficult to identify those things, you are opening up the problems for further on. Developers, they’re making bad choices potentially and then not being clear to users exactly what these things represent. It’s all about representation and semantics. Hopefully that answered your question.

Yeah, as I say, these things need to come together with another question. We get this a lot rarely is so one of the people I don’t think they were actually were able to make it on the call, but they asked this on Eventbrite when they registered, which is that sometimes it feels like coders use accessibility to play points, to say, you can’t do that because of accessibility. It’s almost like a blocker to the things that you personally don’t like in code. I think we both agree that that’s not the best way of thinking about accessibility and development. What’s a more positive way of thinking about this?

I think the approach should be never use that as a stick, it’s more of, ”We’ve got this product or service, how can we bring that to as many users as possible?” Are there alternative ways of giving this information? To say simple examples, if we have videos, we’ve got captions, and then if we’ve got video without audio, then we’ve got transcripts. So it’s just, you can do things as long as you have alternative ways of understanding what we are trying to convey. So that’s the most important thing.

In many cases you can come up with something it is about being inventive and coming up with new concepts. Never just saying, well, it’s not possible. Obviously, when it comes to the fundamental things, bad practise is bad practise. But if you have something that you need to share to your customers and your users, then it’s really important that we think of ways, come up with ideas, of conveying that. The challenge there is more effort because you need to come up with ideas, you need to design those ideas, just develop them. That means more time within the project. That needs to be factored in when we are coming up with new ideas.

Great stuff. Thanks, Usman. Just one last thing. Today you have been giving a lot of people a lot of training in accessibility. Somebody asked, do developers get this by default? If you want to learn coding and you go on a coding course from another training organisation, will they include things about accessibility in there? What do you think?

There are many courses which do include some aspects of accessibility. I think the challenge is that within the industry is still seen as an afterthought, not as important as the actual implementation of something itself. We need to make something. It’s about, let’s make it and then think of the accessibility of that thing. We really need to change the discussion around. If you are within a business, how can I make sure that we are reaching as many customers as possible. As a business, that’s what you want, you want to present to as many people as possible. It means about producing quality. Quality is what is lacking a lot of in many organisations. Because when you are having to think more about how we are presenting our code, we are marking up the various different ways that users can retrieve this information. It’s a lot more effort.

So it’s more about quality rather than quantity, not producing so much, but think about how you are doing it. But definitely many courses do have that information, but it requires a lot of effort, there’s testing, manual testing that needs to be done because if you develop a code component in isolation, you might make that component totally accessible. But then how does it work in a full solution within that product and service? How’s the journey constructed together with your accessible component? That can only be done through user testing, manual testing, and developers need to be involved in those testing also. So compiling pages, testing entire pages, testing the screen leaders, etc. There definitely is a gap still.

Thank you Usman. That’s great.