An In-depth Introduction to the WordPress Block Editor for Screen Reader Users (Part Four)
Introduction
Welcome to the WordPress Block Editor Tutorial Part Four of a Series!
This tutorial will cover many different concepts and topics when it comes to using the WordPress Block Editor. However, the tutorial will primarily focus on using the block editor in conjunction with a keyboard and screen reader.
This document is the first part of three (3) parts on the FSE (Full Site Editor). Details that were covered during the lecture/presentation such as the tour of the FSE will be presented in the documentation in the next part of the tutorial series. The decision was made so that certain features can be properly tied together explaining the workflow. The audio lecture/presentation discusses basic concepts and principles that will become clearer as we progress through learning about the FSE.
Acknowledgements
Special thanks go to the following contributors:
- Amanda Carson for co-authoring and proof reading parts of this tutorial.
- David Edick for setting Up and hosting the Zoom conference for us to demonstrate the concepts detailed in this series as well as recording and editing the user zoom sessions.
- Jason Castonguay for assisting in researching and testing of the Mac Keystrokes so this information can be Updated.
Topics and Concepts that will be covered:
- What are blocks in WordPress
- Tools used for tutorial
- Anatomy of a Theme
- What’s in a Name
- style.css
- functions.php
- PHP template Parts
- “Always-used” Templates
- Files in the WordPress Hierarchy
- Template Parts
What Are Blocks In WordPress?
Blocks are the components for adding content in the new WordPress editor. They are used to transform a single document into a collection of discrete elements, each of which has an explicit, easy-to-change structure. Block structure and settings are separate from the settings for the entire document, and block settings and Post/Page settings have their own distinct parts within the editor’s user interface.
Tools used for tutorial
- WordPress 6.8using the twenty twenty-five (2025) theme
- Browsers: Mozilla Firefox, Google Chrome, Safari and Microsoft Edge; all browsers kept up to date.
- Screen readers: JAWS 2025, NVDA 2024 and Microsoft Narrator (Windows 11) as well as VoiceOver (MacOS Sequoia 15)
The Anatomy Of A Theme
What’s in a Name?
WordPress decides how to treat theme files based on their name. The first thing to notice is that every file in any theme directory has a special name. functions.php, style.css, index.php — none of these files are named by accident, and none of their names are arbitrary. WordPress decides how to treat theme files based on their name. It has a special treatment written out for functions.php, (lower-case and with (functions” spelled correctly), but none at all for functionz.php, (lower-case, but with “functionz” spelled with a Z instead of with an S). It goes without saying that should you spell “functions” with an upper-case F, which is allowed under Linux in order to distinguish the file with a capitalized name from the file without a capitalized name, WordPress would treat this file like any other that doesn’t conform to what it expects when it comes to naming conventions. So if you upload a set of instructions as functions.php, (spelled correctly), WordPress will interpret them; but if you upload those same instructions as functionz.php, (spelled incorrectly), WordPress will just ignore that file and its instructions completely.
style.css
style.css is the main source of your theme’s visual appearance. As such, it dictates everything from the choice of fonts and colors to whether or not your theme is responsive. It’s also where you’ll be doing the bulk of your work to make your site look the way you want. style.css is Also how you Register Your Theme, because it contains a comment section in its header, which is where theme data such as the theme name, author, parent theme if any, and so on, are registered.
WordPress reads these comments to get its information about your theme. So the little comment block at the top of your theme’s main style sheet, and nothing fancier or more technical, is what causes your theme to appear in your site’s list of themes in Appearance > Themes in the WordPress admin area.
functions.php
functions.php is where you add custom functionality to your theme. This could be an awful lot, including:
- Adding CSS stylesheets (including style.css itself) and JavaScript files
- Registering nav menu areas and widget areas
- Defining which custom image sizes you want to be available on your site
- Filtering your page content
functions.php “talks to” the rest of WordPress primarily through WordPress hooks (also called action and filter hooks), which let it add functionality at just the right places.
PHP Template Files
A WordPress site’s template files determine the site’s markup. Without them, there’s literally nothing on the page. The main bulk of a theme’s files are its PHP template files. If functions.php is a theme’s brain, and style.css is its clothes, template files are its body.
Together, these files determine the site’s markup: the actual HTML that the browser displays when it renders your site. They do this in two ways: 1. HTMLFirst. Template files do print HTML directly to the browser, just like a regular .html file would. Anything not inside isn’t PHP: it’s just plain HTML that goes straight onto the page. So if a theme’s header.php includes a bit of HTML such as the following: <body class="site-body"> That’s exactly what a browser will see on every WordPress webpage that includes header.php, which should be all of them. 2. PHPTemplate files really work their magic using PHP, which is interpreted as HTML along with programmatic instructions by your server’s running copy of php.
As a simple example, our same header.php file could instead contain the following code: <body class="<?php echo ‘site-body’; ?>"> The added PHP simply echoes (prints) the string “site-body” right onto the page.
So the server did extra PHP processing on its end, but the browser still sees the same old HTML. As you can imagine, a theme’s template files are utterly crucial: without them, there’s quite literally nothing on the page.
“Always-Used” Templates
Some template files are used on every webpage on a site. The major examples are header.php and footer.php. These files are used so often that WordPress has special functions for including them in other template files: get_header() and get_footer(). Called this way, without parameters, those functions simply grab header.php and footer.php, and drop them in where the function was called. Why are these files used everywhere? It’s because most sites want a consistent header and footer across different pages. If one page has your company’s logo and primary nav menu, it’s a good bet that you’ll want other pages to do the same. The same is true for your footer at the bottom of the page.
As a note, sidebar.php is also sort of this kind of file, although it’s a hold-over from when WordPress was blogging software and when sites had sidebars. Like header and footer, sidebar has its own function as well, get_sidebar().
Files in the WordPress Template Hierarchy
The real excitement happens in files like index.php, single.php, and page.php. These files dictate what markup will appear for different kinds of post data. For example:
- If the webpage being requested involves a Page-type post (for example, your About page), WordPress will likely use page.php to build that webpage.
- If the requested webpage is an individual Post-type post (for example, you’re viewing a particular blog post), WordPress will likely use single.php to build it.
- If you’re looking through all the Post-type posts you wrote in 2014, WordPress will likely use archive.php to build that webpage.
These “in-the-template-hierarchy” template files all share something very important: They’re build around The Loop, one of the absolute core principles of WordPress development which we’ll discuss in a later lecture.
Template Parts
Let’s say there’s a section of both index.php and page.php that’s exactly the same. Should we repeat that code in both those files?Actually, DRY (“Don’t Repeat Yourself!”), is a battle cry for good programmers. Repetition causes all kinds of problems. What if you want to change something about the repeated section? Now you’ve got to change it in two places. What if you forget to change it in one place, or make a mistake in one file but not another? Now your code is out-of-sync and your site is buggy. (Now: what if you repeat the same code twenty times? You’ve got to repeat every change you make times twenty, and hope that you “caught them all.”) Template parts take a likely-to-be-repeated part of a template file, and move them out into a new file. This way, both index.php and page.php can both simply refer to the same template part, rather than individually writing it twice; and if you want to change that section you only change it once.
These are the things to really understand about a WordPress theme. Even a way-too-big ThemeForest theme will be built around this core skeleton, so understand how these pieces interlock and you’ll have a lot of power to understand WordPress themes, and by extension, your WordPress-powered site.