Welcome to the eighty-third episode of Access On, the National Federation of the Blind's Technology podcast.
Episode
Listen to the eighty-third episode of the Access On podcast (Browser).
Or listen on your preferred podcast platform.
Timestamps
- The building blocks of the web 0:01:02
- The importance of semantic structure 0:24:38
- Introduction to content management systems 0:43:47
- Closing and contact info 0:54:51
Transcript
Speaker 1:
Live life you want.
Speaker 2:
Access On.
Jonathan Mosen:
Welcome to Access On, the technology podcast of the National Federation of the Blind. This week, we begin a series on websites taken from a recent Access On seminar. We explain how the web works and discuss tools to help you create and maintain websites. It's Jonathan Mosen at the Jernigan Institute in Baltimore, Maryland, welcoming you to episode 83 of the podcast. This one produced before National Convention because it is coming out on the final day of National Convention.
But if you are home or you're perhaps traveling home when you hear this, I hope that you had a wonderful National Convention season. We will be bringing you some highlights from National Convention in due course, right here on Access On. But let's begin with this series on the web, and we're going to start off with the building blocks of the web. What actually is a website under the hood? And to tell us all about that, here's Ron Miller.
Ron Miller:
Let's talk about the building blocks of the web and what the internet is versus the web. What's the difference? People often use the terms internet and web interchangeably, but they're different concepts. The internet is a global system of interconnected computer networks. Basically, it's the huge network of hardware and cables that links computers worldwide.
In contrast, the web, again, short for the World Wide Web, is a collection of information that is accessed via the internet. In other words, the internet is the infrastructure, while the web is a service built on top of the infrastructure. The internet includes all kinds of online communication: email, file transfers, online gaming, et cetera. Whereas the web specifically refers to websites and pages accessible through a browser.
The internet is the underlying network of networks. Think of it as the physical and technical backbone connecting millions of devices globally. The World Wide Web is an application of the internet, a vast collection of interlinked digital pages and media, which we navigate using web browsers. Whenever you click a link or visit a website, you're using the web, which in turn is using the internet to fetch and display that information. It's like the relationship between a road system and the postal service. The internet is the road network and the web is like a postal service delivering specific packages, web pages over the roads.
Now, let me give you a brief history of the internet and the web. Each of them have their own separate history. The internet's roots traced back to the ARPANET. ARPA stands for Advanced Research Projects Agency Network, ARPANET, a project funded by the U.S. Department of Defense. In October 1969, the first message was sent between two ARPANET computers. It actually wasn't a complete message. One of the computers was at UCLA, one was at Stanford University.
Now, the first attempt crashed, they were trying to send the word login. They only got the letters LO sent for login before the systems crashed, but that was the start of something a whole lot bigger. By December of 1969, there were four computers connected on ARPANET. And over the next decade, more networks of computers were added. They formed more networks, and the engineers realized that they needed a common set of rules so all the networks could work together and all the computers could communicate with each other over these networks.
So finally, on January 1st of 1983, ARPANET officially adopted what is called TCP/IP, which stands for Transmission Control Protocol and Internet Protocol. A set of standard communications protocols every connected computer must follow. This moment is often cited as the birth of the modern internet because it allowed previously separate networks to interconnect freely as one global network.
A few years later in 1989, a computer scientist named Tim Berners-Lee at CERN, which is a research institute in Switzerland, proposed the concept of a World Wide Web, a system of interconnected documents accessible through the internet. By 1990, Berner-Lee had built the first web browser and web server, and created the very first webpage. He also designed the core technologies of the web, HTML to structure content, and HTTP, which we hear about all the time when we do webpages, which stands for Hypertext Transfer Protocol, to transfer webpages, and URLs, a term we have also heard of before, I'm sure, which stands for Uniform Resource Locators, the addresses of webpages. So you know where put a URL into your browser and the page is delivered to your computer. The World Wide Web was born.
In 1991, the first website was made public, and this was a website which discussed the web itself. So the first webpage talked about the web. In 1993, the decision was made to make the web technologies free and open for anyone to use. So they became open source, they became publicly available. And this open availability contributed hugely to the web's growth. By the mid-1990s, websites and browsers became more common and ordinary people started surfing the web. I've presented just a few milestones.
I want to leave you with the concept that the internet came first as a networking infrastructure. That was the 1960s to the 1980s. And then the web came later, around 1989, as a way to use that infrastructure to link and share documents globally. Now that we know what the internet is, and a bit of its history, let's talk about how the internet actually works. What are its components and structure?
There are two main aspects to the internet's design. Hardware. The internet consists of a vast array of physical devices and connections. This includes everything from the cables, copper wires, fiber optic strands under the ocean, et cetera, that carry data to the computers and devices, just like your computer or your smartphones. Then they connect to the network. It also includes the intermediate hardware that keeps data moving, such as routers. Those are specialized devices that direct data traffic. They route the traffic. Switches, modems, cell towers, satellites, and a whole lot more.
Essentially, any device that helps route or deliver data is part of the internet's hardware. Even the device you're using right now is an endpoint of the internet hardware. It's where the files and documents are delivered to you. So think of the routers as traffic directors. They help data packets, which are small chunks of information. They help them find their way through the network to the right destination. Servers are powerful computers that store websites, emails, and other data, and they serve them to users upon request. So, a server literally serves the information to you, but they are computers with a lot of memory, a lot of processing power.
They are usually not just standalone. There are rooms full of servers to serve all of the clients. And clients are the devices we use, like our personal computers, our smartphones, that request and receive data from the servers. And remember, all this happens on the infrastructure of the internet, all the devices, all the cables, all the connectors and routers and everything. These physical components interconnect in a huge web.
Some parts of the hardware network form the internet backbone that carry enormous amounts of traffic across continents and oceans. Other parts are more local, like your home router, which you have to have when you get cable service and you get internet service. Or even your mobile phone tower that carries your phone signals to your phone and away from your phone back to the server. Connections can be wired. So physical cables, fiber optics. Or they can be wireless, radio waves.
That's all wifi is. When you think about wifi, we talk about wifi, or Bluetooth or even your cellular service, it's all just a form of radio. And it's radio that networks, even up to satellites and back, these radio signals are part of that network. You've got protocols, which we talked about earlier, which are communication rules. If hardware is the body of the internet, then protocols are its language and rules. The internet works because all these diverse devices agree on how they can communicate with each other.
A protocol is essentially an agreed upon set of rules or procedures for communications. The most fundamental protocol to the internet is the TCP/IP, defines how data should be packaged into small pieces, which are called packets, and how they're addressed, transmitted, routed, and received on the network or through the network. And thanks to these protocols, any computer on the internet can find any other computer and send data reliably, even if the data has to hop through many intermediate points.
There's other protocols layered on top for specific uses. For example, HTTP, which we mentioned, Hypertext Transfer Protocol, is the set of rules used specifically to transfer webpages over the network. SMTP, which is simple mail transfer protocol, is used for sending emails and so on. And each type of internet activity, browsing, email, file transfers, all of these things that you do on the web has protocols suited for it, but they all rely on the underlying TCP/IP to get data from point A to point B.
So TCP/IP is the foundational protocol and everything else is built on top. When you connect to the internet, your device, whether it's your phone, your computer, uses internet protocols to send and receive data across various pieces of network hardware all over the world. If you send an email or request a webpage, that information is broken into packets which travel through routers and cables, and possibly even go through multiple cities and satellites, and even different countries, and they finally get reassembled at the destination device.
It happens in seconds, sometimes less than a second, so it's pretty fast. What's interesting to me, because of the way this works is, because your packets can take different paths and then get reassembled at the destination device, you might get packets for a document or a song or an email, and they come in out of order, but they're all labeled according to the protocol, and they're all reassembled, and they're presented to you in the proper order. They're all assembled correctly.
So now, let's take a look at the World Wide Web itself, the part of the internet that deals with websites, web content. What are the key components that make the web work? The web is essentially made up of webpages, which are documents that are usually written in HTML, and we'll talk about that in a moment, and that can contain text, images, links, and other media. A website is a collection of related webpages.
For example, if I go to nfb.org, there's all kinds of links, there's all kinds of material on this website, the nfb.org website. It can contain multiple pages. There's a webpage about our Center for Excellence in Nonvisual Accessibility. And within the center page, there's links to other center-related pages. So each page has a unique URL. Remember, Uniform Resource Locator, URL. In this case, it's nfb.org. And you can think of this as an address for that page on the internet, or for that website on the internet.
Web servers, these are the computers that we mentioned a moment ago. They store webpages and they make them available over the internet. When you visit a website, your computer, which is the client, remember, actually contacts a server somewhere in the world and asks it for the webpage that you want to view. The server then sends that page data back to your browser on your computer, which is the client.
A web browser like Microsoft Edge or Chrome or Firefox, Safari on your iPhone or on your Mac, is the application on your device that retrieves and displays the webpages. It's what you use to surf the web. The browser's job is to understand the code, the HTML code and other related code, remember according to those communications protocols, that describes a page, and then it presents it to you in a readable or audible format. Your screen reader gets that information from your browser, which of course gets it from the server via the internet.
Let's talk about Hypertext Transfer Protocol, HTTP. This is the primary protocol of the web. This defines how webpages are requested and transmitted from the server to browsers to the clients. So when you enter a web address, a URL such as nfb.org, or you activate a link, your browser sends an HTTP request to the server that hosts that page. The server then responds over the internet connection with the page data using HTTP to structure that response.
In other words, HTTP is the language that browsers and web servers use to talk to each other for web content. What is a hyperlink? A defining feature of the web is the hyperlink, or we call it a link. The hypertext part of HyperText Markup Language, HTML. Hyperlinks are those clickable references. Visually, they're often underlined or colored text. This also includes other clickable elements that connect one webpage to another.
So you can activate a link. If we're using a screen reader like NVDA or JAWS or Narrator, we can press enter to invoke those links, to activate those links, and they allow you to jump between webpages instantly. You don't have to type in another URL, you just activate the link. This ability to link documents together into a web of information is what made the web so revolutionary.
It's why it's called a web, because everything is interlinked like a spider's web. Modern webpages can include images, audio, video, interactive forms and more. However, behind the scenes, all these elements are included via HTML code, it's all hypertext code, and related web technologies. They're all bound together in that big network, that big web. For an accessible experience, especially for screen reader users, webpages use proper structure.
So headings, lists, alternative text for images, those kinds of things, to ensure that all the users can navigate and understand the content. They're all accessible, whether you can see it or not, whether you're relying on speech or Braille feedback. If a webpage is structured properly and follows the rules for these protocols, they are accessible. In essence, the web provides an easy to use interface to the internet's information. You don't have to manually send packets. You don't have to understand networking to use the web.
You simply use a browser and you follow links or you search for content. The browser and the web servers handle all the internet communication in the background using HTTP and other protocols that we've talked about to get you the information that you requested. And what is the material that holds these webpages together? It's largely HTML. So let's look at HTML a little more deeply now.
HTML is the language of the web. So what does it do? HTML stands for HyperText Markup Language, HTML. It's the standard coding language used to create webpages on the World Wide Web. You can think of HTML as the skeleton or the framework of almost every webpage. You as a user might not see HTML code, especially when you browse, it's working behind the scenes in every site that you visit. HTML is what makes that site what it is. It's the building blocks for the website, if you will. It's the language that that site is communicated in.
So, key points you might want to know about HTML. It's all about the structure. It's not style, it's structure. HTML's main job is to describe the structure and the meaning of the content on a page. It's not a programming language in the traditional sense. It's a markup language. That means it marks up our labels, pieces of the content like headings, paragraphs, links, other elements on that page, so that a web browser knows what they are.
For example, HTML lets us specify that, "This is a heading." You go into the nfb.org webpage and you'll find if you press H or shift H, you can step through our main homepage or other subordinate pages by headings. Those headings are defined using the markup language, using HTML. Also, the web browser is told, "This is a paragraph. This is a paragraph of the text," or, "This is part of a list of items."
By itself, the browser doesn't know this. It does know it through the markup language. HTML is the foundation. Without it, a browser won't know how to arrange text versus images versus links on the page. The web browser doesn't know what to do. The hypertext and links are what makes links possible. This refers to HTML's ability to make hyperlinks, clickable connections to other pages, as we've mentioned earlier.
HTML has a tag, a code element for links, which is what allows one page to lead to another, to lead to another, forming that web. So there are tags that have addresses. They're called anchors, also. The anchor lets you move from, let's say, the nfb.org page to another page that might not be featured in a link on the NFB's homepage. That concept of hypertext documents linked to other documents is central to what Tim Berner-Lee's creation of the web was all about.
HTML is also designed to be relatively human-readable. The texts are written in such a way that you can look at HTML, the raw HTML code and understand it. It's written very symmetrically, text that are enclosed in tags and angle brackets. So for example, if I want to show that there's a tag, I might have, for example, lesser than, and then the tag name and then a greater-than sign. You might say, "Less than H1," for heading level one, and then a greater then.
So that says, "Okay, this is a heading at level one." And then the word, "Welcome," and then a less-than sign and a slash, and then H1 and the greater-than sign. So, less-than, H1, greater-than says, "Oh, this is the beginning of a heading." The heading is going to say, "Welcome." And then less-than/H1, greater-than, the slash indicates, "Oh, this is the end of that heading." And of course, it's still contained in the less-than and greater-than signs.
A browser would interpret this and display the word "welcome" as a heading at level one. Okay. And that's as deep as I'm going to go into this, but I just want you to understand that there is a symmetry in HTML. And you won't need to memorize any of this, these tags and these kind of things. The browser takes care of all this, but what's important to take away from this is that HTML is a markup language that has a symmetry to it.
If the rules are followed, if the structure and symmetry are followed, the web browser will be able to interpret it and display the page correctly. And for us, equally importantly, it allows our screen readers to look at that code and interpret the webpage in a way that lets the screen reader give us the page, whether it's in speech or in Braille, in a way that we can actually consume this information.
So when I'm creating a webpage and I'm using HTML, I'm going to be using the tags, headings, P within the less-than greater-than for a paragraph, a number of other things that will show up, and those will delineate the content in between them. I'll have a tag for opening the paragraph, a tag for closing that paragraph string, a tag for the heading, a tag for a link.
And if I build my HTML according to the rules, the symmetrical markup that it needs, it will always let my browser and my screen reader be able to properly interpret this, and interpret it in a usable way. If I don't do it right, then things can be broken. My webpage visually looks funny, that document looks weird, and my screen reader, of course, won't know what to do with it either. Think of this symmetry in the same way you might think of symmetry in some applications when you're writing a document.
If you use opening quotations, you need to close that quotation with a closing quotation. If you have an opening parentheses, you need a closing parentheses, an end parentheses. It works the same way in HTML. If you've got an opening tag for a paragraph, a heading, if you're delineating a link, if you're starting or stopping a list, any of those things, you're making cells in a table, you must have, for the most part, opening and closing tags for whatever element you're setting up in your HTML document, just to, I hope, help you to understand what I mean when I talk about symmetry.
An important thing to bear in mind is that this symmetry and this structure is important, especially when you're using access technology. It's all about organization and clarity. Every piece of content has a clear beginning and end. That's what those tags are for. That's what they're used for. And it makes the page logically organized. Have you ever gone to a webpage and you are reading down through the page and you encounter a heading, text that should be a heading, level two or level three, whatever, it's part of the document, if you will, of the webpage?
It's a subordinate point of some sort, but the heading never ends, and you read down through paragraphs and paragraphs of material, and in Braille they're underlined, indicating a heading. With speech, your screen reader keeps saying, "Heading, heading, heading" as you keep moving from line to line.
It's possible whoever designed this webpage put the opening tag for a heading at level whatever and they never stopped it. They never put the closing tag, let's say, for heading level two. And so, the browser and your screen reader keeps thinking that, "Oh, this is one giant heading." I don't know if it bothers you, but I could tell you it definitely bothers me when that happens, and the delineation is broken because there's a tag missing.
Jonathan Mosen:
That's Ron Miller. And when we come back after the break, Charles Hiser picks up this theme and looks at the importance of semantic structure on the web, as Access On continues.
Speaker 5:
For over 100 years, the American Action Fund for Blind Children and Adults has provided programs and services to the blind and deafblind, mostly without cost and always with an emphasis on Braille.
Thousands of Braille books and Braille calendars sent, and thousands more blind and deafblind people to reach. Help the American Action Fund by contributing today at actionfund.org/donate. Thank you for your support.
Charles Hiser:
When creating content for the web, it's important to think about how that content is laid out. You could write some content, put some images on a page, upload that page, and there you go, you have a webpage. And most people would be able to go and read that page, see those images, and they would understand what you mean. But the more content you introduce onto a page, the more important it becomes to structure that content into easily digestible chunks, and semantic structure can help you do that.
Now, semantics is usually something that people encounter in terms of language. In the context of language, semantic usually means an organized hierarchical system of meaning, where words, phrases, and sentences are structured to convey specific interpreted information rather than just relying on the literal definitions of words.
Semantics in HTML are very similar. You can write HTML and it's possible to understand what that HTML is saying, but when speaking about semantics, that refers to HTML that uses elements with meaningful names and purposes, like headings, lists, buttons, and other elements. When you're talking about semantically structuring a page, you want to think about how you want the information to relate to each other and to the page as a whole.
For example, it's possible to create regions in HTML. You may have a header region, a main region, and a footer region, and each of those regions is going to contain content based on where it sits on the page and what you want to do with that content. Headers and footers usually contain the same information, whether you're on a homepage, an about page, or a form that you're filling out, whereas the main page information changes to match what you're trying to do on that specific page.
You can also use headings to represent smaller chunks of that information. So in your main section, you may have an About Us heading, a heading for recently posted social media posts, and you may have a heading listing the most important links that go to other parts of your page that also might be found in the header and footer, but that are organized differently on the main part of your page. Using semantics in HTML allows you to structure all of this so that it is easily findable and navigable for all users.
Let's now talk about some basics in terms of elements that you can use to give yourself some structure on your page. The first thing I'd like to talk about are lists. There are two basic types of lists in HTML, unordered and ordered lists. They each start and end with their own tags and the list items are represented slightly differently.
Unordered list items are represented by default with a little black circled bullet, and ordered lists are represented by default numerically, one, two, three, four, et cetera. To start and end an unordered list, you use the UL tag, and to start and end an ordered list, you use the OL tag. The list items are represented with LI, and as soon as you use the LI tag, you also put in the text of whatever item you would like to represent.
Unordered lists are used for when you don't need to put the items in any particular order and most of the time this is what is encountered on webpages. You want to use lists to group items together, but a lot of times you don't need them to be read in a specific order. It's just that it's better represented if those items are grouped together. So unordered lists are good for most of the time. If you want to represent, say, a process that needs to be done in a specific order, you might use an ordered list with the OL, start and end tags. Then, your steps would be listed as one, two, three, four, five. However many items you have, it will be automatically numbered for you.
You can also create what's called a description list, which don't seem to be used as much, but it's worth talking about that it is a possibility. Description lists allow you to write in descriptors of each list item, if you so choose. You can use the DL tag to start and end a description list, the DT tag as the descriptive list item, and the DD tag as the tag to write descriptions for each item. Again, these don't seem to be used as much, but it is an option. You can mix and match lists, you can nest lists within each other, you can use different lists across your webpage or even website. Hopefully this overview is enough to show you some of the possibilities.
The next element type we'll discuss are headings. Headings can be at different heading levels from one to six, and those heading levels help inform users what type of content they're looking at. Content that is under a heading level one is usually main content. There's usually also on heading level one on a page, in most instances. That heading describes the entire page's content, similar to the page title attribute. Heading level twos are usually subsections of that main content. They describe large sections of content that may or may not then be broken down into even smaller chunks.
For example, if we were talking about a recipe, you may use heading level twos to describe the general recipe characteristics and ingredients section, and then reviews about that recipe. You can then use headings at level three to go into even more detail. For example, in the characteristics section, you might talk about taste, color, presentation and texture. The ingredients section may have heading level threes for dry ingredients and wet ingredient preparation, and the reviews section may have heading level threes for each review. You can use heading levels four, five, and six as well. Keeping in mind that the further into the heading levels you go, the more granular the content which they head should be. You can then move back up to the previous heading level to indicate that you are moving on to a new section.
One other thing to note about when you use heading levels is that it will change the size of your font. A lot of people like to use this for visual styling, but that wasn't the original purpose of heading levels. And when you're talking about navigating the web with access technology, that really gets confusing for those people who rely on heading levels to understand the relationship of the various pieces of content to each other on a page. So it's very important that when you're thinking about heading levels, you consider that you are making an outline for your page, or maybe a table of contents is a better way to put it, depending on your page content. The headings should generally describe the content which they head, and if there is no content to head, then headings should not be employed.
Finally, I'd like to talk about regions on a page. Most of the time, you have a header, a main, and a footer region. You can also have nav regions, which are usually used for navigation bars or navigation link menus. But right now, we're going to focus on headers, mains, and footers. Headers and footers on a webpage generally contain the same type of information across your website. A header is usually going to have some kind of main menu, navigation section, where a footer will usually contain something like the copyright information, author information, contact us links, and some other generally useful pieces of information.
The main region is something that users will look for to find the beginning and end of the main content to help differentiate between the header and footer content. Again, this is really helpful for access technology users who rely on semantics to better understand the structure of the page. It seems kind of intuitive when you're talking through it like this, but headers, mains, and footers really offer simple and instructive semantics so that people can easily jump to whatever pieces of content they're looking for.
This is by no means an exhaustive list of semantic elements that you can use, but this gives you the general idea, that when you're talking about HTML semantics, you're talking about elements whose names mean something, unlike div or span, for example, which do mean something to an HTML developer, but maybe not so much to the end user. So, I encourage you to explore what types of content you want to design and how you would use some semantic elements to make that more accessible to people. But it's not just enough to have semantics. You also want to look good. And in that vein, we are going to talk about how to do that.
Some of this might sound familiar if you attended our document webinar last month, and that's intentional. We'll talk a little bit later about how you can design a Word document and then turn it into a webpage. You can also do a similar thing using code editors and any number of HTML editors that you can find online. When you're thinking about visual design, a few things need to be considered. Similar to using semantic design, a good visual design can guide people's attention to where you want it to go. It can help increase the accessibility and it can help your page reflow so that it can fit on all sorts of different sizes of screens, from laptops to tablets, to phones to big monitors.
You can use HTML to control these aspects, and you can also use CSS, or Cascading Style Sheets, to visually alter your content without actually changing the HTML structure of your content. You can change visually where your content appears while keeping it in the same order in the accessibility tree view. You can change color, font size, and more, all using CSS. You do need to be careful that you do this in an accessible way, and that goes beyond the scope of this webinar, but it's worth saying that sometimes CSS implementation can cause some interesting bugs when it comes to access technology. So, make sure that you or someone you know runs through your webpage so that everything works the way you think it should.
A couple other things to note when you're talking about visual design, it's important that any image that you have is either hidden from access technologies if it could be considered decorative, such as if you're using icons to represent common actions. And images that are visible to access technologies have alt text so that people using screen readers, or people's browsers that don't load the image properly can understand what the content of that image is supposed to be.
Before I go any further, I'd like to talk a little about Web Content Accessibility Guidelines. WCAG 2.2 is organized into 13 guidelines, with 87 total criteria, 56 of which are supposed to be met for Level AA compliance, which is the legal standard recognized by many countries around the world and usually followed by organizations publishing any kind of web content, such as websites, applications, documents, and anything you will be able to find online.
These guidelines cover everything from semantic structure, like we talked about earlier, to the way that a website looks, the language used on the website, and some other things to make everything as accessible as possible to as many people as possible. It's important to talk about this because these guidelines inform the legal standards of accessibility around the world. So if you want to follow the law, you need to follow WCAG.
Most of the time, as long as you don't get too complicated, you probably will follow WCAG, but it's still good to know that these exist and to double-check yourself as you design your content, just to be sure. One of the things that WCAG talks about is the language that you use in your web content. The guidelines around language ensure that plain language is used so that your content can be understood by as many people as possible, and it does make exceptions for technical content.
It doesn't mean that everything on the web needs to be plain language, but if you want people to be able to understand what you're trying to get them to do or know what certain controls are for, those need to be described in plain language. If your content is designed to be accessed by a wide population, you should think about the types of words that you use. Avoid overly long or complicated phrasing and make sure that you use words that are in the general vernacular.
You can also think about the way that you structure your words, such as where you create a new paragraph, how you phrase your sentences, and even which words you use and how many times you use them. Good writing is definitely a skill, and writing for the web is a subset of that skill. Thinking about the way that your writing is structured can help underscore whatever points you're trying to make, or help highlight whatever content you would like the user to focus on most.
Speaking of highlighting, one way that a lot of people like to highlight their content is by using colors. Coloring different words allows the eye to be more naturally drawn to certain types of content. And that's all well and good, but you need to be aware that WCAG does suggest certain color contrast ratios to make it easier for people to read this content. Now, the term color contrast is a little misleading because it doesn't actually have to do with the color, but rather the luminosity or the brightness of whatever shades you're using.
When you're talking about contrast ratios, you're comparing the brightest color to the darkest color, whether that bright color is in the foreground or the background, and vice versa. Your text can be the bright color or the background can be the bright color, but either way, when you talk about these ratios, the first number is the brighter color and the second number is the darker color.
WCAG recommends that your brighter color be about 4.5 times brighter than your darker color, unless you're working with fonts in a large print size, something like 18 point or above, or roughly 14 point bolded font. And this is a little subjective because it depends on what font you're using. When you're working with a bigger font like that, WCAG recommends that you have a 3:1 contrast ratio, where your brighter color is three times brighter than your darker color.
Something else to think about while considering the way that you're going to be writing your content is if you're going to include any interactive elements within that writing. For example, a lot of websites will use links in the middle of written text so that users can click on a, "Learn more" or, "Click here" link. Some people prefer that links say what they are linking to. Instead of saying, "Learn more," the link could say, "learn more about this recipe."
It is a small difference, but it can make a big impact for users who are navigating specifically by link, or screen reader users who might be navigating by links or element lists. Something else to keep in mind too is the labels on your buttons or check boxes or radio boxes. As they directly relate to the content that you're writing, it might be very important for some users to understand your content to have those labels be as specific as possible. It's easy to think that people would be able to pick up on context clues, but not everybody processes written content the same way. So, designing with a little bit of redundancy in mind in the way that you label your elements is a good idea, just to cover all of your bases.
Whatever the purpose of your website, thinking about the way that your content will be perceived by the end user is a great idea. Walking through how you want the user to look at your webpages, how you want them to operate or find the different controls related to your webpages, and even the content itself. Where do you want their eyes to go? How do you want their screen readers to move? In what ways do you think is going to be best for them to move through the content? Dividing your content up by semantic elements, like headings and lists, can really help people understand content in smaller digestible chunks, and also find the types of content that they need.
Using different colors to highlight sections is a great idea, as long as you make sure that it contrasts well with its background and surrounding content. Thinking about font sizes and even different fonts across your webpage can really help draw attention to certain sections, or can help minimize attention to other sections, unless users are specifically looking for it. In the end, your website is your creation, and you shouldn't be afraid to show that.
Use the chance that you have to create your own website to show your unique personality or the personality of your brand. Considering what colors you use and the fonts you use can send a message all on its own, regardless of the content that you have. Once you take into account the way that you present your content, you're sending a complete message to everybody who views your website. Also, think about the fact that if you are an access technology user, other people may use their technologies differently or be using entirely different technologies.
Just because it's accessible to you does not necessarily mean that it will be accessible to somebody else. So if possible, try and test your webpages with different technologies and different users, seeking feedback from the disabled community, and especially those who are professionals in the field of accessibility, will really help add a layer of robustness to your website so it is accessible to as many people as possible.
In just a little bit, we're going to talk about some content management systems that can help give you a head start. It is possible to design all of this by hand and to lay everything out, write all of your code, check it with an editor, check the final viewing and build through iteration, but you don't have to. There are plenty of content management systems and we'll talk about some of them throughout the presentation. So, please stick around and enjoy.
Speaker 7:
Here's a simple yet powerful way to celebrate while giving back. Your birthday is right around the corner, and instead of just receiving well wishes and gifts, you have the opportunity to make a difference by starting a birthday fundraiser for the National Federation of the Blind on Facebook.
It's easy. When your special day approaches, Facebook will nudge you to kick off a birthday fundraiser. All you have to do is select the National Federation of the Blind as the beneficiary and set your fundraising goal. Then, it's time to spread the word.
Post a status update explaining why the National Federation of the Blind is close to your heart, and how your friends and family can join in making a difference. By using your birthday as a platform for giving, you're not just celebrating another year older, you're using your special day to support a cause that truly matters.
So, when your birthday rolls around, don't forget to start a Facebook birthday fundraiser for the National Federation of the Blind. Together, let's make every birthday count.
Jonathan Mosen:
Now, a look at websites continues, as Kennedy Zimnik introduces content management systems.
Kennedy Zimnik:
A content management system is basically a tool that lets you create, edit, organize, and publish website content without needing to hand code every page from scratch. So instead of opening a blank code editor and writing all the HTML, CSS, and other behind the scenes code yourself, a CMS gives you a more structured environment. You can usually log into a dashboard, choose options from menus, write content into editing fields, upload images, create pages. You can do anything you want with the CMS.
A CMS is like the control center for a website. If the public website is what visitors see, the CMS is a private area where you build and manage that website. Some common examples of content management systems include WordPress, Drupal, Wix, Squarespace, and Shopify. These platforms are not exactly the same. They serve the same general purpose. They help people create and manage websites more easily.
This matters because producing a website from scratch can be difficult. You need to understand code, file structure, hosting, design, layout, navigation, images, forms, and of course, accessibility. A CMS can make that process much more manageable because it organizes many of those tasks into a system. That does not mean a CMS automatically makes website creation easy or automatically accessible, but it can give us more of a practical starting point. When using a CMS, you are usually working with a few main parts.
First is the dashboard or admin area. This is where you log in and control the site. You might need to create new pages, update existing content, install plugins, manage users, and you can also check form submissions in this area. Then you have the content editor. This is where you write and format the information that appears on the website. Depending on the platform, this might feel like working in a word processor with options for headings, paragraphs, links, et cetera, all the other pieces you need for our website.
Next is the theme or template. This controls the overall visual design of the site. The theme determines things like page layout, font choices, colors, menus, a lot of the CSS things that you'll hear about today. Also, there are often plugins, extensions, or apps. These are add-ons that give the website extra features. For example, you might install a plugin for contact forms, event calendars, search engine optimization, e-commerce, security, or accessibility testing. So, the CMS is kind of like a middleman between you and the finished website. You provide the content and make decisions and the CMS helps turn that into webpages.
Now, one important thing to understand is that a CMS does not remove the need to understand website structure. It just changes how we interact with that structure. For example, you still need to know what makes a good heading. You still need to know when something should be a list, how to write descriptive link text, why images need alt text, that a website should be organized in a logical way. This is especially important from an accessibility perspective, of course. A CMS can either support accessibility or make it harder, depending on how it's built and how you use it. Let's use headings, for example.
Most CMS editors will let you highlight text and choose heading one, two, three, and so on. For blind people using a screen reader, this is very familiar because headings are one of the main ways we navigate digital content. But visually, many people use headings just to make texts bigger or bold. That can create problems. On a website, headings are not just visual decorations. They create the outline of the page.
And another major piece is link text. In a CMS, it is usually very easy to add a link. You select text, choose the link option, paste it in the address, and save it. But the accessibility issue is not whether the link technically works. It's whether the link makes sense. A link that says "click here" is not very helpful, especially if a screen reader user pulls up a list of links on the page. If there are five links called, "Click here," nobody knows where they go. A better link would say something like, "Register for more Access On seminars, read the Braille Monitor, or donate to the National Federation of the Blind here." Hint, hint.
Another important area is images. Most CMS platforms allow you to upload images and add alternative text. For blind website creators, adding alt texts may feel intimidating, but there are tools that you can use to get descriptions of images. That is a bit out of the scope for this presentation, but I am mostly referring to AI apps and tools like Gemini or ChatGPT.
If you're uploading an image that someone else provided, ask them what is in the image and why it matters. If you're working with a team, make alt text part of the content creation process. If you're using AI to help describe an image, review the description carefully and make sure it matches the purpose of the image. A CMS gives you the feel for alt text. The level of accessibility depends on how thoughtfully you fill it in.
Another accessibility angle is forms. Many websites need forms, registration forms, contact forms, newsletter signups, donation forms, and surveys are all common examples. In a CMS, forms are often created with a plugin or form builder. These tools can be very convenient, but the accessibility of the forms must be considered. A form needs to clear labels. A person using a screen reader should know what each field is asking for. If there's an error, the error message should be understandable and easy to find. So when choosing a CMS or plugin, ask yourself, "Can it make an accessible form?"
This is a big theme with content management systems. The feature existing does not always mean the feature is accessible. For example, we see this all the time. A drag and drop page builder might sound easy, but it may be difficult or close to impossible to use with a screen reader. A nice template might look professional but have poor color contrast. So, when we talk about producing a website as a blind person, we are really thinking about two layers of accessibility.
The first layer is, "Can I, as the website creator, use the CMS accessibly? Can I navigate the dashboard, create and edit pages, add links and headings, publish content? I mean, can I review what I created accessibly?" The second layer is, "Will the website I produce be accessible to visitors? Can it be navigated only by keyboard, WCAG standards?" A CMS can be accessible for the editor but still produce inaccessible pages, or it can produce decent front end pages but have an admin dashboard that is frustrating for a blind person to use.
For many people, WordPress is a common starting point because it is widely used, flexible, and has a large community. But even with WordPress, accessibility depends heavily on the theme, the plugins, and the editor experience. Drupal is another major content management system, and it is often used for larger, more complex websites, including universities, government agencies, nonprofits, and organizations that need strong content organization.
Compared to WordPress, Drupal can have a steeper learning curve, but it is powerful when a site needs detailed user permissions, structured content types, and more customized workflows. From an accessibility standpoint, Drupal has a strong reputation for supporting accessibility in its core system, but just like WordPress, the final experience still depends on the theme, modules, and design choices used on the site.
Platforms like Wix or Squarespace may be simpler in some ways because they handle hosting and design in a more packaged environment, but they also may rely heavily on visual editing, things like drag and drop layout and design controls that are not always ideal for non-visual use. And Shopify is common for online stores, but e-commerce adds extra complexity, as product pages, shopping carts, checkout forms, images, et cetera, need to be accessible.
So there's no one perfect CMS for blind person for every project. The right choice depends on what you're trying to build, how much control you need, and how comfortable you are with the technology. Jonathan will cover some CMS I mentioned before in depth in the next section. Because producing a website is not just about launching it once, websites need updates, things like event date changes, staff pages change, links break, plugins need updating, contact information changes, and of course, new content gets added sometimes every day.
A CMS is valuable because it allows for ongoing management. You do not want to need a developer every single time you need to fix a typo or add an announcement. For blind creators, one of the best approaches is to separate content from layout as much as possible. Focus on creating well-structured content first, use a theme or template to handle the visual presentation. This is much more manageable than trying to visually design every page from scratch. A good website does not need to be visually complicated. It needs to be clear, organized, usable, and professional.
Another useful strategy is to build repeatable patterns. If your website has event pages, create a standard format, for example, event title, date and time, location or Zoom information, short description, who should attend, et cetera. Once that pattern is established, you are not reinventing the page every time. You're filling in a reliable structure. This is helpful for a person maintaining the website and it is also helpful for visitors. Consistency is universal accessibility. People should not have to relearn how your website works on every page, and everybody likes a consistent website.
As a blind person creating a website, you can do a lot of accessibility checking yourself. Navigate the published page with your screen reader. This is where you can flex your screen reader abilities and make an accessible site with a great user experience. You can also use automated accessibility checkers, but it is important to understand their limits. They can tell you whether you have alt text or not. They can't tell you whether that alt text makes sense or not. It can tell you whether a form has a label, but they can't tell you whether if that form's label makes sense, things like that.
So the strongest approach is a combination. Use your screen reader, use keyboard testing, use automated tools when helpful, and when possible, get feedback from other users. Also, don't underestimate the value of sighted review for visual polish. Accessibility does not mean ignoring visual appearance. If you are blind and producing a public-facing website, it may be helpful to have a trusted sighted person check spacing, alignment, image placement, and visual consistency.
Also, AI has gotten much better over the past few years at visual interpretation. Plug in your website and get visual descriptions on it. The goal is to not do every single thing alone. The goal is to have enough knowledge and control to lead the process, make informed decisions, and produce a website that is both accessible and professional. So to summarize, a content management system is a tool that helps you build and maintain a website without coding every page manually. Remembering that good web design is not just about how a site looks, it is about how well people can use it.
Jonathan Mosen:
And as Kennedy said, we will get into the weeds, as it were, and look at some of these specific content management systems next week, as our series on designing websites continues.
That concludes this episode of Access On, the technology podcast of the National Federation of the Blind. To send in a contribution for a future episode, email us, attach an audio clip or just write it down and send it to [email protected]. That's [email protected].
To keep up to date with Access On, follow us on Mastodon, [email protected]. That's [email protected] on Mastodon. To subscribe to an announcement only email list about upcoming episodes, send a blank message to [email protected]. That's [email protected].
To learn more about the National Federation of the Blind, visit our website, ngb.org. Or phone us, 410-659-9314. That's 410-659-9314. And be sure to check out the Nation's Blind Podcast right from where you heard this podcast.