Building an Accessible and Highly Usable Transportation Website: Ron Zasadzinski and Kevin Sholander

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup, Building an Accessible and Highly Usable Transportation Website with Ron and Kevin from CodeGeek. I have a few announcements before I introduce our speakers. The first one, if you are not aware, we do have a Facebook group, which is a great place to connect in between meetups. You can find it if you just search WordPress Accessibility on Facebook or if you go to facebook.com/groups/wordpress.accessibility. You can share what you’re working on, get feedback, help other people, ask questions, answer questions, all of that great stuff. It’s a good community. Everyone always asks, “Is this meetup being recorded?” The answer is yes, it is being recorded. It takes us about two weeks to get corrected captions and a full transcript, and then we will post up the recording on our website. You can find both upcoming events and past recordings in one place if you go to equalizedigital.com/meetup.

The other way to get notified of recording availability is by joining our e-mail list and that you can do if you go to equalizedigital.com/focus-state. We also release these episodes in audio format only for people who have said they prefer to listen while they’re out walking their dog or doing chores around the house instead of watching. You can find the audio of past meetup episodes, as well as our conversation episodes on accessibility and craft beverages on our podcast, which is at accessibilitycraft.com.

We are seeking additional sponsors for the meetup. While this is part of the official meetup program, the WordPress community team has told us that they don’t, unfortunately, have funds to help cover the cost of live captioning, ASL, and post-event transcription. They said, “Go out and find sponsors.” If you or your company would be interested in helping to support the accessibility of the meetup, we would very much appreciate it and we’re happy to send you over information about what that entails and the benefits that we give to our sponsors.

You can contact us at meetup@equalizedigital.com, and that will go to myself and Paula to get information about that. That is also a great e-mail to use if you have questions, following a meetup, if you have any suggestions for how we can make it better, or if you need any additional accommodations to make the meetup work well for you. I am Amber Hinds. If you haven’t been before, I’m the CEO of a company called Equalize Digital. We are the organizers of the WordPress Accessibility Meetup. Today we are also the sponsor for captions because we don’t have a different sponsor for captions.

We are a mission-driven organization and a corporate member of the International Association of Accessibility Professionals, which is abbreviated IAAP. We are focused on WordPress accessibility and we have a WordPress plugin called Accessibility Checker that scans for accessibility problems and provides reports on the post-edit screen to help make building accessible websites easier. You can learn more about us on our website at equalizedigital.com. We are most commonly on X as far as platforms, and you can find us there at Equalize Digital.

We do have a sponsor for our sign language interpretation today who I want to thank, and that is Ninja Forms. If you have not found the interpretation view, I would love to call it out for you. At the bottom of the Zoom bar, now this may be under the ‘more’ depending upon how wide or narrow you’ve made your browser, but there is an icon that looks like a globe and it should say interpretation next to it. If you click that, you can open a separate window in order to see our sign language interpreters.

They do a phenomenal job and I would definitely recommend checking out the interpretation. Of course, if you need it, but also it’s interesting to take a look at the signing for presentations, even if you are not a American sign language speaker. Ninja Forms has very generously covered the cost of sign language interpretations for the past three meetups. Ninja Forms, if you’re not familiar with them, is one of WordPress’s oldest form builders. They are proud to serve users from all around the world, all walks of life, and different stages of online growth.

From small businesses and local non-profits that make up the core Ninja Forms user base, to universities, hospitals, and even some Fortune 500 companies use Ninja Forms. They will scale with you or your clients from startup to wherever you’re aiming for. They also have been working quite a bit on improving the accessibility of their plug-in. If you go to watch the past recordings, you can find a talk from Quay Morgan of Ninja Forms talking about their journey, which he gave a very phenomenal and moving talk about that experience.

He also said it is not as hard as they thought it would be, which is great to hear. Please do, if you have a moment, send them a tweet on X or post on LinkedIn or somewhere and just say, hey, thank you Ninja Forms for sponsoring ASL for WordPress Accessibility Meetup. We always encourage people to thank our sponsors. It helps make them want to sponsor again and to know that what they’re doing makes a difference. If you want to learn more about Ninja Forms, the plug-in, you can go to ninjaforms.com. On X, they are just at Ninja Forms.

We are already at the end of the year, which I can hardly believe, but there are only three more meetups left in 2024. On Monday, November 18th at– not 10:00 AM Central, I apologize, we’re off on our time on the slide, at 7:00 PM Central time, so our normal Monday meetup time, Joe Dolson will be speaking about managing plug-in accessibility for the long-term. Anyone who is a plug-in developer, whether you are a commercial plug-in developer or someone who builds plug-ins for your customer websites, but don’t distribute them outside of that, this would be a great talk to tune in for.

Then in December, we were having a little hard time finding people who were like, “Yes, I will speak around Christmas time,” but we were talking internally about some of the challenges and December is a good time to do planning for the next year. On Thursday, December 5th at 10:00 AM Central time, which is the same time slot as this presentation next month, my partner Chris will be speaking about how to accurately budget for accessibility. If you’re interested in budgeting and planning out budgets related to accessibility remediation, particularly on existing sites or potentially on building for a new website, that will be a talk to come to.

Then on Monday, December 16th, I will be doing an accessibility strategy and goal-setting workshop. This will be a time where you can come. We’re going to have a little bit of presentation, then we’re going to have roundtable and opportunity for discussion, opportunity to just work on some things and then share back. I’m going to get brave and we might even promote some people and allow people to speak, which in the past we haven’t always done, but I think it’ll be a fun, more traditional meetup experience instead of just a webinar. That again is on Monday, December 16th at 7:00 PM Central time.

Of course, why are you here today? I’m very excited to introduce our two speakers, Ron and Kevin. I’m going to add some spotlights so they come up here. Ron is the founder and CEO at CodeGeek, where he and his team have worked with clients all over the US to create custom websites and web apps. I actually have had the pleasure of getting to know Ron through the Fort Collins Accessibility Meetup when I used to live in Fort Collins, Colorado.

I actually learned a lot from him as I was first starting my business, and he very generously shared tons of knowledge, and his dev team would always come to our meetups and always share a lot on the dev front, which I’ve learned a lot from them. I always appreciate that and I’m excited to have Ron here. Kevin is a Senior Web Developer at CodeGeek, who is part of that dev team I said, who knows quite a bit. Kevin has played a pivotal role in crafting websites and web applications that serve diverse clientele, ranging from local businesses to international corporations that work with CodeGeek. Welcome, Ron and Kevin.

>> RON ZASADZINSKI: Thank you very much, Amber.

>> KEVIN SHOLANDER: Thank you.

>> AMBER: What I’m going to do is I’m going to stop sharing. I’m going to let Ron and Kevin take over on the presentation front. We are using the Q&A panel, so you can add any questions that you have into that Q&A panel, and then I will come back at the end and ask them to our speakers.

>> RON: Awesome. Thank you very much, Amber, and hello to everyone here. I’m so grateful that all of you are here and excited to chat together today. Our purpose in this presentation is to share with you a few details that we hope are very helpful for you in building your own accessible and highly usable websites of any type. The mission of this particular project is we were tasked with redesigning and rebuilding the transportation website for the city of Fort Collins, Colorado, which is ridetransfort.com. That’s a combination of transportation and Fort Collins, and to make it conformant with Web Content Accessibility Guidelines, AA, and using WordPress.

That was the primary mission, and at CodeGeek, we wanted to take it a step further and make the website as highly usable as possible for everyone as well. Our aspiration was to make this one of the best transportation websites in the country, and we will show you how we do that. The first thing is all the things you do to make any website accessible. As we know, there’s a fair number of those things. For the WCAG AA level of conformance, there are 55 guidelines that we need to meet all of those. We’re going to do that by applying accessibility techniques, as well as our expertise and our knowledge that we’ve learned over time.

I have learned a lot from Amber as well, especially on accessibility, and I’m just so grateful for Amber and Chris and Equalize Digital. They are an amazing resource for all of us here. There are many phases to this project and any project of this scale. This was an 18-month project, by the way. Planning and architecture, visual design, interaction design, including interaction design for screen readers, meaning how the screen readers are interacting with the website, development, content creation, and content entry.

As you can see, this involves many teammates over a long period of time and many phases of the project. Once we’ve taken care of those or planned out those factors, then we’re going to address unique challenges to this particular website. The part we’re going to focus on today is the bus route schedules which are displayed in tables. Putting tables into a website and making them ages marked up correctly, semantically, as a challenge, and making them accessible is a little bit of a challenge, but we’re going to show you how.

Kevin is going to demonstrate some specific things so you can make any table on your website accessible. Then to take it another step further, we wanted to make the tables usable for all visitors, including those using all of these things. Those consuming content visually, consuming content using screen reader software, using keyboard only, and using mobile devices. All right. Why should you listen to us about this?

I founded CodeGeek 22 years ago, and as the leader of CodeGeek’s team of 12 amazing people, my job is to help us be the best we can be every day. As a company, we prioritize relationships first, both with our clients and internally, as we build accessible websites for clients with local, regional, national, and global reach. We specialize in web accessibility, custom website design, and we are a very technical company and do development in WordPress, Webflow, and build web apps in Laravel. Kevin, do you want to say an additional word or two about yourself?

>> KEVIN: Sure. Let’s see. I’m a senior developer at CodeGeek. I’ve been with them about five years now, just a little over five years. Been in the web development business since 2006, I guess, almost 18 years, and spent a lot of that time doing accessible development. I’m really, really passionate about the accessibility work that I get to do.

>> RON: Thank you, Kevin. Diving into our specific topics for today. As we know, accessibility is a very broad topic, and we’re going to focus on a few key aspects of web accessibility. When you leave today, I’m hoping that you feel like you have picked up one or two tips in each of these four areas. How do you know if any particular website is accessible? Keyboard testing, data tables, and usability. How do you know if any particular website is accessible?

I was talking with a prospect recently, and they were contacting us about doing some accessibility work for them, and I was demonstrating a site that we had built. The prospect said, “I don’t see that little button or that icon that opens up the accessibility panel,” and I was like, “Oh, no, no. That doesn’t mean a website is accessible just because that’s there. It might be. It may not be.” How do you know? Just like in the Lord of the Rings, there’s one ring to rule them all. In web accessibility, there is only one way to know if the website is accessible, and that is through accessibility testing.

There’s three areas that we need to do automated testing, and there are many wonderful tools for automated testing. If you have questions, we can make some recommendations or let you know what we use in the Q&A. Automated testing, depending on who you talk to, can pick up anywhere from 30% to 50% of accessibility challenges that need to be addressed. The other two types of testing are manual; keyboard testing, and we’re going to focus on that today, and screen reader testing. You need to do all three of these in order to figure out how accessible any particular website is. There really is no shortcut to figuring it out.

Let’s talk about keyboard navigation. One of the reasons we’re focusing on this, in addition to it being one of the three key ways that you do accessibility testing, is that keyboard testing can be done by virtually anyone. You can test any website you bump into on the web on your own. This is very helpful information for content creators, as well as developers, website auditors, and website remediators. With the keyboard, what should you test on the website? I will demonstrate some of this.

We want to test all the interactive elements on a web page. Examples, this is not a complete list, include links, buttons, navigation menus, checkboxes, radio buttons, and form fields. Next question is, how do you know what the keyboard behavior should be? What keys should you use to activate a button? We reference the WebAIM keyboard testing document, and that’s at webaim.org/techniques/keyboard, and then scroll down to the testing heading. I’ll show an excerpt from that on the next slide.

With that as our guide, how we implement this testing is our developers perform keyboard testing literally every single day while they are building the website. That catches any errors they may have made as we go, and we can fix them very promptly. Then our internal accessibility auditors will do keyboard testing and a couple of key project milestones. Typically, once we’ve completed building the custom theme, but before content entry, that way we can catch any structural things we need to fix before that content entry phase. Then again, for sure, before the website is launched, we do a full suite of accessibility testing again to make sure we’ve met all the requirements before launch.

This screen shows an excerpt of the WebAIM page, the link I mentioned on the previous slide. There’s more to it than just this, but not too much more. These are the four things we’re going to demonstrate today. Navigating to the interactive elements, we use the Tab key to go forward, and Shift-Tab to go backward through those elements. Links, when you’re on a link, the focus is on a link, the Enter key will activate the link. When you’re on a button, then Enter or Space bar will activate the button. We’ll also look at drop-down menus or any type of select menu. This is applicable too.

Once that drop-down menu is open, we should be able to navigate through those elements in a number of ways, including the up and down arrows. The Tab key should also move through those items, and the Escape key should close that drop-down and return the focus to the parent element. Let’s take a look at this. I will demonstrate this on the ridetransfort.com website using route three, and there’s about 25 bus routes on this website. While we’re going through this, I would like you to pay attention to links, because there are multiple styles for links, depending on the context and the purpose of that link. The same with buttons, there are several styles that you’ll see as we take a look at this page.

Let’s talk about links and buttons, and then after that, I will do the keyboard demo. The first link I’ll point out is a very common link, typical link, where we have it inline within content. We can tell it’s a link because it’s underlined, we’ve also made it bold and a different color to indicate that that’s a link. The function of a link, the behavior of a link, is it should take you to new content. I would expect if I click that link, I’m going to get taken either to a new page, or I’m going to get taken to somewhere else on this page where it may scroll the page I’m on to a new set of content. That’s the purpose of a link, is to take you to new content.

Now, links can appear in other formats, as we know. For example, in the upper right corner where I’m showing here, it looks like there’s two buttons. These are actually links, but we’ve styled them as buttons. They have a horizontal pill shape to them with a dark background and light text. When you read what the link says, view map and timetable, if you think about the behavior of that, what would you expect to happen if I click on that? My expectation is that I would be taken to a PDF and be shown that new content. We’re being taken somewhere to new content.

Same with the trip planner and bus tracker. It looks like a button, but it is actually styled as a link because that’s the behavior that it does. It’s going to take us to a different page. As I keep scrolling down, there are some other buttons on the page. Kevin’s going to demonstrate these buttons for earlier, now, and later relative to the route table. Oh, sorry, those are buttons. I’ll circle back to that in a minute. I’m still talking about links. Let me keep going down to the bottom of the page. In the footer, it’s not uncommon. We know it’s common to find links in the bottom of a footer. We have here several columns, several groups with a heading of lists of links.

These, again, look different, but based on the context, the visual user will recognize that these are links. The point is, you can style links in a variety of ways to meet the objectives of usability for that particular page or that website. Buttons, let’s talk about those for a minute. At the route table here, we have several buttons, earlier, now, and later. Kevin’s going to talk more about these, but for now, I will demonstrate that when I click the button, the button takes an action on the page. That is the behavior of a button.

There are many common examples of how we use buttons. For example, to play a video. When you click that play button, that is taking an action on the page. Filling out a form and then submitting the form. When you click submit, that is taking an action on the page. These buttons here, earlier and later, are taking an action on the page and actually scrolling the content. That’s the difference between links and buttons, is their functionality or their behavior.

Now let’s do some keyboard testing to verify this is working correctly for this page. If I start in the address bar and click the Tab key, the first thing that appears is skip to main content link, which is important for people using screen readers. If they choose to, they can skip the repeated content on the page, in this case, the navigation, and get right to the content. We will keep tabbing, and the next tab highlights a link of the logo in the upper left-hand corner. That link, if we clicked it, would take us to the, or use the Enter key, would take us to the home page.

One more tab forward, and now we’re into the main navigation menu. If I do Shift + Tab, then I go backwards and then to activate the dropdown, we have to think this through a little bit. If I’m going to activate a dropdown and show the sub-navigation, that is actually taking an action on the page. That is a button. What you’re seeing in the focus here is a button, and if I click the return key, it expands that menu and then I can navigate through the submenu with the tab key or the arrow keys and some other ways as well, but those are some of the key ones.

When I press the escape key, that should close that and return the focus to the parent item, which it does. That’s the basics of keyboard testing, and ultimately, if we’re testing the whole page, of course, we would sequence through every link and every button and every interactive element on the page, make sure the correct keys, expected keys, have the correct behavior. Hopefully, that’s helpful. Again, I think it’s so easy to do some keyboard testing, and the references are possible to find. I encourage all of you to try it out on your websites and any website out there.

Summarizing the links versus buttons concept, which I feel is very important, which is why I’m spending this time on it. As we mentioned behavior, links take the visitor to a new location. Buttons trigger an action on the page. Developers, you should be marking up the element according to the behavior it is actually going to take. Links should be marked up with an anchor tag. That would be the semantic HTML element, and buttons would be marked up with the button tag.

Designers, you, of course, should feel free to style the element, whether it’s a link or a button, to look as needed for usability and to guide the visitor’s eye through their user journey that you’ve already designed. In a moment here, Kevin will talk about route tables. On the left-hand column, we have the bus stops, and then in the center area, we have the various times that the bus arrives at each stop, and that bus goes many times through that route in a day.

The keys here are– Kevin’s going to talk about how to implement the table HTML structure in general. That’s applicable to every HTML table you create on the web. We hope this is actually helpful for you as you’re building tables, and then we’ll review how we’ve thought through the accessibility of these route tables and things we did to make them even more usable than just the semantic markup. Kevin, I’ll turn it over to you and stop sharing.

>> KEVIN: Thank you, Ron. I’m going to be talking about how to build tables in HTML and to make them accessible. The key to building anything in HTML is to stick to what we call semantic HTML whenever possible. If you’re not familiar with the term semantic HTML, what I’m referring to there is if a tag exists within the HTML language, then it’s best to use that tag. As Ron was pointing out earlier, there’s a button tag. If you’re going to be building a button, using the button tag would be the best choice there.

You can build buttons out of other things. It is possible. People shouldn’t know that because you’ll be tempted to use that at some point, but if you use the button tag for building a button or a table tag for building a table, then the browser is going to be doing a lot of the work for you that’s required by accessibility. It will recognize the element as being what you’re describing it as. It’s a table, it’s a button and then it will add features and functionality that go along with those.

When you’re building an HTML table, you should always include a caption and if required, a table head section. The caption would be a description of what the table is so that the user will have some notification of– rather than just being dumped into a set of data, they’ll know how that data is relevant to them. Then the T head section is used to mark off a row or multiple rows, that will act as the header of the columns within your table.

I put another note in here. Don’t mess around with default roles unless you really need to, but you shouldn’t need to. In this case, we certainly don’t but in HTML, you can use the language to mark things up so that a div becomes a button, for instance, or a div becomes a table. Again, you really should avoid that kind of behavior because the roles are announced to the user. The user will understand that I’m on a button because the screen reader will recognize the role that’s attached to an element and the user is expecting certain behaviors out of certain roles.

If you go changing roles, you’re going to have to also write a bunch of JavaScript to take care of all that yourself, all the expected behaviors. When you can, avoid messing with the default roles. One extra thing with building a table in particular, adding a scope property to your table headers. That gives an indication to the screen readers whether your table header happens to be a column header, where it’s at the top of the table and it applies to everything underneath, or a row header where it’s at the side of the table and it applies to everything in the row.

Let’s take a look at what that looks like in HTML. Here I’ve got a table in the upper right. It’s a very small table, I’m using it as an example. It has the title at the top, Weekdays Northbound. It’s two rows and two columns. The first row is a row of headers, and the first header in the first column of that row is stop location. The second header in the second column is trip number one. Underneath it, I have a data row where there’s a row header in the farthest left column, and that’s first and main. That’s the street corner at which the bus is expected to stop, and then there’s a data element in the second column of that row, 10:00 AM. I would expect a bus to arrive at 10:00 AM at first and main.

To mark up that table, I’m using a table element. I’ve got the angled brackets with the word table in it. That indicates that the contents of this element is a data table. The first thing at the top there is a caption. I’ve got a caption tag inside of the angled brackets, and it says Weekdays Northbound. The next thing is a table head, which is T head inside the angled brackets again, and inside of the table head, I’ve got a row. In HTML syntax a row is TR in angled brackets. That stands for table row.

Then the table row has two table headers or THs in them. The first one is stop location, and the second one is trip number one. Each of those has a scope property attribute assigned inside the table header definition, where this one says scope equals “col”, where “col” is short for column. The table body is the next element within the table structure, and that’s indicated by a tag T body in angled brackets. Then that also has a single row in it, and that row has a table header, this time with a scope equals row as the attribute instead of scope equals column.

Then it has the header first in main, and the data elements are indicated by a TD tag in square brackets, and then the time, 10:00 AM inside of that. This is very basic for a very small table, but you can expand it to as many rows, as many columns as you need for your particular application.

I want to give a demo on how that ends up being read out as you’re using a screen reader. Let me pull up that. I’m on the page ridetransfort.com/routes/route-6, and here we have a table down in the bottom that is a fairly sizable table. It’s got a bunch of columns, a bunch of rows. I’m going to open up my screen reader. I’m on a Mac, so I’m using VoiceOver. Wouldn’t you know it? My screen reader is not opening at the moment. Let me go pull that up real quick and see what the deal with my screen reader is.

I’ve got my screen reader on, and I’ve opened up a window on my screen that has the screen reader text in it. Personally, I don’t like to hear it reading at me because, especially when I’m talking, it confuses me. I like to just have it open so I can read and see what it’s saying and interact with it that way. I use VoiceOver on the Mac, but if you’re on a different machine or you have a different screen reader, there’s a couple of popular ones out there, NVDA and JAWS are two that I know of, but they all behave basically the same. They allow you to use a special sequence of keys to navigate through the table.

In this case, I’m using up and down arrows to move up and down through the table and left and right arrows to move left and right. Notice as I move through the table, as I move from one column to the next column, the screen reader says, Trip 8 starting at 1:16 PM, then it says 1:19 PM, column 9 of 15. What it’s doing is it’s reading the column header first, then the data cell, and then giving you some context about where you are within– how big the table is.

The column header is Trip 8 starting at 1:16 PM, then the time is 1:19 PM. That’s the cell itself, the data inside the cell, and then where I am is column 9 of 15. When I move between rows, it reads row 6 of 25 and then the row header, Stop 144, Horsetooth and Shields, scheduled time point, and then it reads the data cell, 1:19 PM. As you can see, there’s a lot of information that is conveyed by the screen reader, in addition to just the data cell itself. If you’ve marked up your table correctly, it will be reading off your row headers and your column headers.

One thing that’s interesting to note is that it reads them out even if they are not visible on the screen. This is a table that can be scrolled, and if I scroll far down to the bottom right of the table and go through a cell here, it can still see the table header that’s off the screen at the top or the row header that’s off the screen on the side. I’m going to turn this voiceover back off and move back to– If you mark up your tables correctly using proper semantic HTML, the screen reader will have no trouble figuring out where the headers are and reading out the caption at the top, and navigating through that table will be not too challenging for a screen reader user.

However, there are some issues that visual users are going to run into with large tables. If the table is too wide to fit on the screen or too tall to fit on the screen, those column headers can fall out of view, and while a screen reader can see them, a sighted user will have troubles with navigating that. I wanted to just give a quick demonstration of what I mean by that.

I happen to be a vegetable gardener. I refer to the CSU Extension site frequently, and they have a table on here that has crops or vegetables down the left side and insect pests across the top. I find this table to be somewhat challenging to use because as soon as I zoom in large enough so that I can see the word artichokes here on the left, I’ve lost the table header at the top, and if I scroll up to find the table header, I’ve lost my artichokes here. It’s really challenging to try to keep track of both the headers at the top and on the left.

Being aware of that situation, we wanted to make our tables, which can be quite large and very data-intensive, we wanted to make them as usable as possible. I’m going to switch back over to a demo and just give you an overview of some of the usability features that we’ve inserted in here. In our table, they’re quite large, but we’ve added a tracker that will track your mouse position. As you move through the table, it highlights the column that you’re in so that your eye can easily follow from top to bottom. I’m going from Swallow Station all the way down and pick one at the bottom, CSU Transfer, and I can see it helps your eye to follow from top to bottom.

We also added the ability to select stations by clicking on them, and it will highlight that row, and then when you move your mouse in, you can see that for this particular trip, I’ve got– if I want to get on a bus at Horsetooth and Shields at 3:19 PM, I can see that I’m going to be getting off that bus at 3:28 at Taft Hill in Elizabeth. Adding some of these visual features helps users to navigate this table.

Another thing we added was some filters here that will just reduce the overall data content that’s in that table so that it’s only listing the scheduled time points instead of all the stops. That will help reduce the amount of data that a user is interacting with so that perhaps they can just get to the critical information they’re looking for easier. As you can see, main thing that we did was we wanted to be able to scroll this table left and right because there’s more data than will fit on a screen, especially if you’re on a smaller screen like a mobile device, but even on a desktop, there’s just way too much data horizontally to present on a single screen.

When we scroll it, the problem would be that our stop names or the stop locations would fall off the screen to the left, and then the user wouldn’t know where they are within the table or what stops are where. We ended up building– It just can’t be done in HTML. You can’t have a column that gets locked down and have the rest of the table scroll.

The way we ended up implementing this is as two separate tables, one that is the data table that is fully marked up, as I showed earlier, with the column headers and the row headers, and then a separate table that sits next to it that just has a duplicate of all of those row headers so that they sit next to it, and as you scroll through the table, you can always see where you are, and that table that contains the row headers is sticky and just sits there and doesn’t get scrolled while the data table itself does get scrolled.

Another feature that we added is a search feature that allows us to interact with the data in the table. If we know what we’re looking for, it will help us jump to a particular location. If we’re trying to get to CSU Transfer Station at a particular time, let’s say I get off at work at 5:00 PM and I want to catch a bus around that time, I could put that in there and notice that it will scroll the user down. It will focus in on the cell that is closest to 5:00 PM at CSU Transit Center. In this case, it’s 442.

Then a feature that Ron alluded to earlier is in addition to being able to use my touchpad to scroll left and right here, we added some buttons to make it a little bit easier for users to scroll to earlier and later, and then we added a now button that will jump you right to whatever the current time is. Currently, my clock says 9:50, so the first column is the nine o’clock bus that is somewhere along its route at the moment. The now button will always auto-scroll to the current position.

Something else is when the page is initially loaded, the user will always be scrolled to the now button just in case that’s what they’re looking for. Most people are looking for what time is the next bus, so we auto-jump to now as the default. The solutions we came up with is we added that sticky row header column that’s going to always stay put and allow us to scroll horizontally. We added some visual effects to highlight selected rows and columns so that the user doesn’t have trouble following vertically or horizontally. We added the scroll controls, the now button, and the earlier and later buttons.

We added the filters to reduce the overall content, and we added that custom search feature. The sticky row header is a good technical problem, and I’m just going to approach it at a very high level at this point. I don’t want to dive too deeply into how it works, but we ended up building two separate tables, one that holds the row headers and one that holds the data. The data table itself has to be marked up to include all of the headers, including the row headers but because we don’t want duplicated information, we ended up hiding those headers so they’re invisible.

They are not displayed none because display none would make them not visible to the screen reader. They’re just really, really small and very transparent, and nobody will see them or know they’re there, but they are, and the screen reader knows they’re there. We’ve made that whole second table that just has the sticky row headers area hidden so that the screen readers don’t interact with it at all. Having a duplicate table that has just street names is confusing to a user if they’re tabbing through or using the screen reader to navigate, and they end up in that table, and there’s no data there. It just adds confusion. We hid that from the screen readers.

Then there’s an interactive element there, which I demonstrated when you clicked on a particular stop in the row header. One of the WCAG guidelines states that anything that’s interactive has to be available via keyboard navigation. We added some extra controls to allow for the keyboard. As I tab through, it will actually tab through the row headers in the data table and highlight these so it looks like we’re actually going through, and I can use Enter and Space to interact with those buttons that are there. Oops.

The sticky row header, here is a brief overview of how I’ve structured that. It’s a diagram that has a bunch of boxes in it. This is the way I picture HTML as I’m writing it. I divide things into sections. The outer section is a flexbox. It contains two tables. The table on the left is the sticky row header table. The table on the right is the data table. Each of them has some flex settings to allow it to occupy a certain size portion of the screen. The row headers are set at 33%, and the data table is at 66%. Both of them are allowed to scroll horizontally.

If I have very long stop names, we can scroll that table on the left, and the sticky row header is marked up as being area hidden. Within that sticky row header, I’ve got a bunch of TH elements, which are my table headers with scope row. They’re hidden from the keyboard navigation, so I have no tab index set on them, but they are clickable. Then within the data table on the right side of the screen, I do have, again, the duplicated table headers with scope row. These actually have tab index of zero.

Even though they’re not visible when you tab through and land on one, I use JavaScript to draw a focus box around the sticky row header that corresponds to it, so it looks like you’re tabbing through the sticky row header. Then the table data itself, I had to add tab index equals minus one to allow me to jump focus into this cell, because if you don’t have a tab index, then you can’t focus on it.

One other feature I didn’t demonstrate, but I would like to, is this search feature if I turn my voiceover back on again. When interacting with the search feature, you can select a particular stop, and I can let’s say Horsetooth and Shields, and I choose a stop, say, at 4:00 PM. When I land on the go button, what would normally be read is it’s a button that’s labeled Go, and the word go doesn’t really mean anything to the user.

From a sighted perspective, I expect when I click on the go button, it’s going to take me down into the table, and I’ll land at Horsetooth and Shields at 4:00 PM. However, a screen reader user, this is the only time on this page where we actually force a focus to move from one place to another, and screen reader users can find a forced focus change to be disorienting. You should try to avoid that if possible, and if you are going to do it, you should warn the user that it’s going to happen.

What we did with this go button is by the time you’ve entered your information here, I have JavaScript that’s already looked up the answer, and when I land on the go button, the screen reader is going to read out the answer, and then tell the user that they can go to that cell if they want, and if they choose to click the button, then their focus will change. They’re forewarned that it’s going to happen. Watch what happens when I land on the go button. The screen reader is going to say, a bus arrives at Horsetooth and Shields. It’s going faster than I can read it.

Bus arrives at Horsetooth and Shields at 3:19 PM. Go to the table cell button group. It says you’re on a button. It’s labeled go to the table cell, so when they click it, they know they’re going to end up there. When I actually do click it, I’m taken to Horsetooth and Shields at 2:09 PM. It says you’re currently on the cell inside of a table. Turning off the screen reader. In order to accomplish most of these features, it required the addition of custom JavaScript. We’re using that to track our focus, see when the tab ordered or when a user is tabbing through, and then we add indicators to our sticky row headers.

We’re monitoring the mouse positions so that we can highlight those columns. We’re listening for clicks on those sticky row headers so that we can highlight the rows. We’re responding to the scroll buttons earlier or later and scrolling an appropriate amount. If you’re on a small screen, it’s only going to scroll a little amount, and if you’re on a large screen, it scrolls a larger amount. Again, we don’t want to disorient the user, so we never scroll beyond what is visible. If you look at where we are in the table right now, we’ve got 2:16 PM over here on the right. If I click later, 2:16 is still visible.

We didn’t want things to scroll beyond the width of the screen. If I go to a mobile device or a narrower view of this and go to the first, I’ve got 8:16 AM here as the last column on the right. When I click the later button, notice 8:16 just moved over here. It didn’t disappear off the screen because then the user wouldn’t know if they missed columns or not. These buttons up here are sensitive to the width of the screen and will only scroll as much as needed or as much as is available in order to keep a column visible.

The now button looks at the current time and will scroll the table appropriately. We have JavaScript that will do the search function and manage the focus into the table. We’re listening for those filtering buttons up at the top that will reduce or show table data, and then we have JavaScript that makes announcements when the table data is changed. There’s some additional buttons up at the top, and it’s always a good idea when a button performs an action. Actions are oftentimes visual, and screen reader users won’t know what happened if they can’t see it.

Whenever a button changes content somewhere– Let me bring up my screen reader again. When I’m on a particular button, say southbound button, currently we’re looking at the weekdays northbound table, but if I click the southbound table or button, it says the route timetable is now showing weekdays southbound and then some dates. Then it says route timetable is showing all stops, 23 rows. Every time I interact with one of these buttons, it will tell me the route timetable is now showing six rows or eight rows, or we’re showing all stops and we’re seeing 23 rows.

It gives an indication that the button click did something, and then it also tells the user what that click did. If you’re working in WordPress, there’s a handy library there called wp.a11y that’s built into WordPress. It has within it a speak function, so you can go to wp.a11y.speak, put in some string in there, and it will tell the screen reader to read that information. The takeaways from this development project that we did are accessible and usable, apply regardless of what technology a user is coming to our site with.

If they’re using screen readers, we want the site to be as accessible and usable for those users. If they’re using a desktop browser with a mouse, it should be as usable as possible. If they are coming with a mobile device that’s a narrow screen, we still want it to be accessible and usable, that all of the features, all of the functions that are available to a user with any other technologies, will be able to use it with the technologies that they are interacting with.

Something to be aware of is that if you are adding features or functions that benefit one set of users, it might change the experience for other users. If you’re adding buttons that can be clicked on with a mouse, they might clutter the screen with information, and it might affect the visual view. Just be aware of decisions as you make them, and keep all of your users in mind at each step of the design process, so that as you’re designing the site, you’re thinking about how users with screen readers are going to interact, or how users with a mouse are going to interact. Regardless of the complexity of your site, there are solutions available. You might have to be creative, but it can be done, and you can keep an interesting and appealing site with lots of complexity accessible to all of your users. All right, I’m going to switch back over to Ron at this point.

>> RON: Thank you, Kevin. Share my screen. That was a lot of information from Kevin, and it reminds me to also share that not only are there more than one way to do things, but we are always open to learning. I think that’s an important part of being a good web developer, and we’re always interested to learn new techniques. That’s part of the equation of what we love about web development. What we’re saying isn’t the only way to do things necessarily. All right, let’s see. Just a few more slides to wrap us up here. Recapping our goal, we wanted to make the website route tables accessible and as usable as possible for everyone.

Usability part. How do we make the website as usable as possible? We have our own opinions about it. We did our own planning at the beginning, working with the client, of course, and came up with a number of things that Kevin’s talked about. Then we also really value outside input. Just because we think something’s a good idea or might be useful, it might be a lot less useful than we thought, and we’d love to get that feedback. during this project, we did do several rounds of usability testing.

One, we had an outside developer review the route tables during the development process, and he was very experienced with accessibility and a very experienced developer, and that provided some very helpful insights to make the system even better. Then after the website was launched, we have done some usability testing with a person who is blind or visually impaired, who uses public transportation and the JAWS screen reader, and that was wonderful. We wrote up specific scenarios to be tested, and we hired an outside agency, Equalize Digital, to facilitate the usability testing process and provide a report.

That also revealed and provided lots of useful feedback. In fact, we have a number of things on our future queue to implement based on this most recent usability test. I encourage everyone to consider getting outside people and users and visitors to provide feedback as well. Our thoughts about the future of this website and how we’re going to continue to maintain it. In my mind, one of the most important things about web accessibility is that it is an ongoing process. The accessibility of your website changes over time. There’s several ways that could happen. One is during content entry.

A content editor could be adding a new page or could be adding new content to a page. They need to be, of course, applying accessibility techniques in order to keep the website accessible. If they didn’t do everything they needed to, that could impact the accessibility. Then even if you didn’t change the content on your website after it’s launched, it could still change. The accessibility could still change. For example, when you run WordPress core software updates and or plug-in updates, if one of those updates somehow change the HTML output to the browser, that could change the accessibility of the site as well.

We believe the best practice is regular attention, and we do that through what we call monthly accessibility plans. After a website is launched, we use these. It includes a specific number of hours each month for accessibility testing and remediation or fixes. This reveals any new issues that crop up early and provides the means to address them promptly because there’s already budget allocated for working on this. This is a wonderful way to keep the website as accessible as possible. What about usability? That’s accessibility and keeping the website accessible, but from a usability perspective, there’s more we can do as well.

We know that people engage our website or any website in different ways. Usability can be improved by doing periodic usability testing by various types of visitors. As I mentioned, we did that very recently. Our plan is to do this a couple of times a year with the website. One thing that is also true is different visitors, of course, use different navigation and content consumption techniques. This is true for users that even visitors that use the same browser and maybe the same screen reader software. Even if someone is using the same tools, they have developed different habits and different techniques for themselves of how they like to navigate and consume content.

There’s a lot to learn by doing these usability tests and seeing how different people use different technologies. The benefit is that over time, this reveals potential improvements and uncovers challenges that can be reviewed and addressed. Concluding thoughts here, maintaining website accessibility and usability can be accomplished with a philosophy of continual improvement and applying regular attention and effort. I do want to also mention that as citizens of Fort Collins, we commend the city and the whole transport team for their desire and commitment to make their websites and physical infrastructure accessible and usable. Let’s build websites for everyone. Amber, back to you.

>> AMBER: Thank you so much, Ron and Kevin. That was a great presentation. I do have some questions. Do you want to stop sharing?

>> RON: Oh, yes.

>> AMBER: For anyone, if you have additional questions for Ron and Kevin about this website or other topics related to accessibility or testing, feel free to put those in the Q&A panel and I will pass them along. I’m going to go in order, but I’m also going to jump around a little bit based on what I think is most relevant. I know at the beginning you were talking about your testing process and someone asked if you could share what automated testing tools you prefer to use.

>> RON: Absolutely. At CodeGeek, we actually use the Equalize Digital’s accessibility checker plugin. We find that extremely useful and powerful. That is one of the primary automated tools we use. There are many other good ones out there that we have used as well. Wave is a free tool that you can test one page at a time, so that’s excellent. There’s a browser plugin for it. Other tools out there, we have used PowerMapper, which is a company out of the UK, and that allows you to test an entire website in one go and get a CSV file output of all the accessibility challenges.

Then Axe, the Axe tools by Deque are also very good. We have not used those ourselves. We’ve been focusing on the other tools, but there’s other sets of wonderful automated tools there.

>> KEVIN: During the development process, we also use a node package called Pali CI, Continuous Integration, and that’s built into our toolset so that as a developer, I can run that before I do any commits into the repo just to check to make sure that things are not being broken accessibility-wise. I believe that’s built on top of the Axe tools.

>> AMBER: That checks basically as you’re writing code in whatever your preferred Notepad++ or Sublime Text or wherever it is you write code, it checks the JavaScript and the HTML, correct?

>> KEVIN: It checks the HTML. It doesn’t do keyboard testing, or it doesn’t do screen reader testing, so we still have to do those manually. It does the automated checking to make sure that our buttons are marked up correctly or we’re not missing all tags and just the basic underlying HTML stuff.

>> AMBER: The other thing that’s good on a dev level, it only works if you have a public repo, so that doesn’t always work well for client work. Axe Linter and I don’t know if you all have used that at all, but it lints. Of course, it’s also not great for– it doesn’t function for PHP, but it does all JavaScript and HTML files, and on GitHub, pull requests, it will lint them and put errors on the PR and say if there’s accessibility issues. That’s another one worth exploring potentially for people. I want to jump down to– there was a question about timeline and then another one that I think is a good follow-up that we got early on.

You had stated that Transport was an 18-month project. How long did you spend on the planning phase, and then how did you manage QA? Could you maybe just broadly tell us all of the phases and their month duration in there? I’d be curious about that.

>> RON: Sure. I’ll go from memory, so this isn’t necessarily exactly correct, but it will be directionally correct. I would say the discovery phase was probably about three months. It was pretty long. They were not in a hurry to get the project launched by a particular date other than meeting Colorado accessibility requirements, so we took our time on the discovery phase. That was complex because we just talked about the front end of the website, but the back end is very complex as well. To get all that route data into the website, there’s a– I guess I shouldn’t pass too much detail.

>> AMBER: Is it coming off an API?

>> RON: No, they export that data.

>> AMBER: Do they build a lot of buck in?

>> RON: It’s like a, what, 30,000 or 40,000 row CSV file that we then import and parse all that data to create those tables on the website. They update those routes. The route changes three times a year, but they make little changes all the time. We built some really nice systems for them to import a new CSV, test it first and see it, and then publish it if they want to and they can immediately roll back to it at any point if they didn’t like what they did. Anyway, so there’s a lot to scope out besides just the front-end pieces, so that was about a three-month process.

Design was a few months as well. That was probably two or three months altogether, maybe two. Then the rest of it really was development and QA. Then managing QA, so we do try to manage QA throughout the whole process so that it’s not overwhelming at any one point in time. As Kevin mentioned, our developers are using a command line tool to test the things that are automated, can be tested in an automated fashion against the WCAG guidelines, and they’re doing keyboard testing as they go. Many of our developers use some screen reader testing on their own as well as they’re going through.

Then at other key points, we’ll have our internal auditor do the full round of accessibility testing. It’s pretty quick because Accessibility Checker can provide a report for the whole site. There’s usually not that many issues because developers have been fixing them as they go. That’s the overall picture, but feel free to ask more detailed questions. Of course, Amber, feel free to pose additional questions or add info.

>> AMBER: I think Leslie’s question is a good follow-up on that, which is, how can you estimate how long accessibility testing will take to properly build it into your estimates? How were you thinking about this when you were budgeting this project out for the client?

>> RON: That is an excellent question. It’s one of those, I think, learning from experience. Part of it is because we’ve now built QA testing into our process throughout the design and build process, it really is just an integrated part. It does add some time, of course. There are other variables including how many pages of the site need to be tested at the end before launch. If it’s a 600-page website, there’s a lot more to do. You might not test every page. There’s ways to do that. It varies, is what I would say. Developing this into a continuous process where we’re doing just spot QA at a few key milestones does help make that a little more predictable.

We really just go on experience from similar projects of similar size as to how much budget we add for that part of the project.

>> KEVIN: From a developer point of view, I would say that making a site fully accessible adds probably 33% to 40% on top of what a normal non-accessible–

>> AMBER: From a time perspective, you mean?

>> KEVIN: From a time perspective. I find as a developer, I spend about 1/3 of my time or a little bit more working on accessibility exclusively.

>> AMBER: I think it’s interesting, though, because, like you were saying, Ron, if you’re doing a lot of that testing earlier, then maybe your QA phase might end up being lower because whoever’s QAing and finding problems might find fewer because the developer’s self-identified and fixed. It’s just shifting where some of that time goes to a degree, potentially. I’d imagine also if you’ve built a lot of websites and you have a library of code, you say, “Oh, we built a similar component for this website. I could pull this in and just restyle it and make a few other minor adjustments or something.”

>> RON: Absolutely. Yes, we do exactly that. Oh, and one other piece relative to the timing, we try to have the website, all the content is entered and QA primarily done about a month before launch for a site of this complexity so that the client who has seen the site along the way as well, but they have their own QA window that will provide to them before launch and then a content freeze that lasts a while as well. For something of this long, we plan to have really it’s all wrapped up about a month before launch so that that final QA phase is very minor. We’re just taking care of little things, but there’s no rush.

That does add to the timeline, but it’s a much better experience for the client and for us except the very end.

>> AMBER: Do you include accessibility QA in your designs?

>> RON: We do. We do it for– there’s accessibility QA really from every phase, including planning and architecture design for sure, and of course, as we talk about development content creation. We’re not doing the content creating. We’re providing guidance and feedback to the client or the copywriters of good format so that they’re specifying the heading levels, for example right in the content as they’re creating it, and that all the heading level rules are being followed and so on.

>> KEVIN: There’s a level of collaboration between the design and development during the design phase where various features are included in the design. Then we get from a developer point of view, how hard is this going to be? Is it possible? Can we sit down and we think about are there ways that we can adjust this table to make it more usable or more friendly? It’s a very collaborative process.

>> AMBER: I think that 30% to 40%, that is in line with our experience as well and what I’ve heard other people say. If you’re just getting started, it might be 40% to 50% increase in time, depending on what it is. I almost feel like, and I don’t know if you have this story, but like the very first one you did, you were like, “Okay, we’re just chalking this up to a learning experience, not really a profitable project.” [chuckles] There’s always one of those, but you do get, I think, more optimized as you go.

>> RON: Absolutely. We all get more efficient at it the more we do it.

>> AMBER: I just wanted to share this, Thomas says, “I love that you are inclusive of people with disabilities in your user testing. I feel strongly that the future of accessibility is not just meeting WCAG requirements, but meeting users’ expectations, so kudos.” Obviously, we worked with you on the screen reader user testing, and we ended up actually, in addition to what you talked about, we had a second user come in and do iPhone mobile so that we could have the touch accessibility.

I know you did other user testing beyond that with the website. Could you talk just a little bit about your thoughts around user testing and how you built some of those scenarios or thought about what do we need to ask people to do in order to figure out if this website is going to work for the broader public who needs to ride the bus?

>> RON: Absolutely. I would say in general, on usability testing, again, you’re having somebody from the outside test out some scenarios that you have created to see how it actually works in the real world. That’s the essential piece. Any amount of it is better than none and a little more is always a little bit better. Ideally, maybe three people would test from the outside, three to five, and you’re going to capture a lot of the usability issues with that number of people. Our plan is to keep doing this, as I mentioned, over time, now that the website’s live, because there’s so much you could learn by doing more usability testing. Our plan is to do more as we go.

If you’re interested in learning more about usability testing, two references that I like are both by Steve Krug. The book Don’t Make Me Think. It’s been around a long time. It’s an excellent book just on web usability in general, but chapter nine covers usability testing specifically. There’s enough information in there to help you write good scenarios. You want to write very specific things. For example, we gave scenarios like, you’re at this address, you want to pick up a bus. If you’re at this address, you’re trying to get this address by this time and then have them try to accomplish their goal.

>> AMBER: Can you figure out when you’d need to leave?

>> RON: Yes, exactly, and then have specific questions to answer on the way. Exactly. Those are good. Then his other book is Rocket Surgery Made Easy, which is all about usability testing. If you’re planning to do usability testing in-house where you’re going to facilitate external people, that book is very good as well. Then the other option is to hire an outside firm, which really enjoyed working with Equalize Digital and thought that was an excellent way to go.

>> AMBER: Thank you. Let’s see. I’m going to go back up here real quick. I’m just trying to get specific. Jeff had asked if you could talk just a little bit more about mobile accessibility. Are there specific things that you put into that beyond what you were doing for desktop?

>> RON: Kevin, do you want to speak to that?

>> KEVIN: There’s not really a whole lot of difference, I wouldn’t say, other than how you lay out maps and how things become visible on the screen, the sizes, dimensions. It’s basic responsive design, responsive layout.

>> RON: I can add to that, and bounce off what you’re saying there, Kevin. When we design the website, we plan, of course, for mobile and desktop. Our designer is very good at knowing how to scale content and adjust content positionally as you go either from mobile, if we’re doing a mobile-first build, up to desktop, or from desktop down to mobile. He gives a lot of thought to that and the team gives some collaborative thought to that during the design phase of how should this flow. Then when we are testing, we aren’t testing just at desktop.

When I mentioned the testing we do along the way, we actually are dragging viewports in different browsers from all the way wide to very narrow, because we don’t think in just desktop, tablet, mobile. We think in an infinite continuum of browser widths because that’s really the reality. We actually scale that viewport and are looking for usability issues that arise in that process.

>> AMBER: Anyway.

>> RON: We do that along the way.

>> KEVIN: It’s equally important to test keyboard testing on a mobile device as it is on a desktop because the navigations are so different or appear so differently that different issues can crop up the usability issues or visibility issues.

>> AMBER: A low-vision user might permanently have their browser zoomed in, and so they might actually be getting the mobile menu on a desktop computer.

>> RON: Very true.

>> AMBER: You had mentioned maps and Kaylee had a question about maps that I thought was really good. She asked, how did you handle the accessibility of maps on the website? In particular, curious how you made the information available to screen reader users, as well as how you handled any sort of color issues with displaying multiple lines on the same map. For context, Kaylee is working on a transportation website and the maps have been the biggest struggle for her so far. What can you share about maps?

>> RON: My answer to that is, it’s a work in progress, and it’s very challenging. The client is working to create very good alt text that describes that image. That’s one of the things that they are in. They update those frequently, and so there’s a lot of that in their court to apply. That’s the state of it so far. I’m not sure I can speak to it too much more than that, other than then yes, this is one of the big challenging areas, just like PDFs and other things as well. The documents that are attached are a big challenge. Amber, I’d be curious. I don’t know if you have any thoughts on that as well. Especially on that.

>> AMBER: I would say the biggest things to look out for on maps is one, you have to think about, is this actually the right format to convey the information? Only because I’ve seen some really complex maps that are just like an image and then people open them on mobile and they’re so tiny that you can’t get anything out of it, so maybe simplifying. I know on your website, you have lines, and they’re labeled for roads, then the client has created them or whatever, but they’re not like showing every cross street and every–

What is the simplified information that can still communicate about the route without having all these landmarks and all these other things that are just going to be clutter, especially when it gets very small on a mobile device? Of course, you have to pass color contrast. You need to make sure that you’re not using color alone to denote important things. For example, if you were to have two routes on a map, you might want to have one solid line, one dash line, or one that has circles for the stops and one that has squares for the stops, something like that, so that it’s clear to be able to denote which one is which one.

I’ll say more broadly, though, in all of the user testing that we’ve done and even beyond with this particular website, most screen reader users ignore map images. I know on the transport website, the maps are in an accordion. They’re an image, but they’re collapsed. They’re not just surfaced by default, so someone would have to be like, “I want to see this,” and choose to view it. We did ask both of those testers, “Would you go?” They’re like, “No, map images don’t ever do anything for me.” You want to make sure that you can have information available in other ways.

For example, on yours, they can see all the stops that that route goes to just by going down the header column in the table, and that communicates the similar information of what stops are they in and in what order. I think that that’s a thing that I think about maps are really hard. The other thing I would say is feedback we got actually from both users on this is that Google Maps works really well for them. They said their default is maybe we’re just going to go to Google and be like, “Tell me what bus stop is near me.”

Potentially not having a image of a route, but building it onto a Google Map, or linking over to it on a Google Map, maybe might be a decent alternative to an image map. I don’t know. Only because of feedback that we’ve gotten that people say it works well for screen reader users.

>> KEVIN: I’m curious, we’ve discussed ideas with the client and amongst our team of ways to make them more accessible. One thing that has come up is the alt text is WCAG says it should be only so long, like 250 characters or something. There are so many words, I forget. It might be nice to have a much more detailed description of the bus stops at this location, it goes a 1/4 mile down the street and turns right on this street, and then it goes to this street. If we had an optional read this map to me button, that would then go through the entire very detailed list of what all the stops are, how far apart they are, what the street names are, that was optionally triggered by a button.

>> AMBER: I could see actually having an accordion that contains a written what we would consider like an audio description. With videos, you can have an audio description track that describes the actions. I think you could have a paragraph that’s written, and then anyone could expand that and read that because there might be people that are sighted, but maybe have cognitive disabilities or find reading a map challenging, that they could then read the narrative about it, or a screen reader user could just have their screen reader read the narrative. I feel like that might be a decent solution.

I would surface it for everyone. Just maybe if you don’t want it to be– if it’s like, “Oh, that’s clutter,” it could be in an accordion or potentially, yes, having a button– it gets more complicated, but you could have a button on or right near the map that then opens the modal that has that in it as well, that would keep it off the main visible content on the page. We have a couple of specific things related to the table that I want to make sure we touch on. Amit asks, can you please explain about scope row and scope column relative to the TH tags in HTML? Would you be able to take that Kevin?

>> KEVIN: Sure. Let’s see. When you’re including a TH tag, TH is of course a table header. There’s no indication of whether the table header is applying horizontally or vertically, it’s just TH. Adding the scope equals column or scope equals row attribute to that TH heading will then indicate whether that heading applies vertically or horizontally. Is that clear enough? [chuckles]

>> AMBER: I think so. I’m also realizing we are, we’re at time, we’re in our buffer zone where we’re about to lose our captioner and our signer. I want to do a quick lightning round and see if we can just answer a few real quick, if that’s all right, and then we’ll wrap off. Thomas had asked, did you have an option to turn off the sticky header or, or columns? Have you considered that?

>> RON: I haven’t. I did read that comment that Thomas put there, that question. I would be very interested in following up with how Thomas would interact with the site and what would the expectation be of turning that feature off as to we expect to find a button that that would say make the whole table scrollable or– because the functionality isn’t hard, but the usability, adding another button and where it sits and how it interacts would be the questions that I would have.

>> AMBER: Maybe Thomas can follow up with you.

>> KEVIN: That would be awesome.

>> AMBER: Let’s see. I want to see if there’s any else specific to– could you talk real quick about integrating accessibility milestone into sprint cycles and roadmaps for continuous improvement? I don’t know, Ron, if you have thoughts about this question that Emily posted.

>> RON: Yes, I would use the monthly accessibility plan approach for that. There’s some budget built into the sprint, some hour budget or whatever for some testing and some remediation in each sprint cycle. That way you’re improving the accessibility as you go. Amber, I think Equalize Digital does something similar. If you’re doing some kind of monthly remediation for a website we didn’t build, we would start with the most important things like navigation, that’s going to be on every page and header and footer. You’re making the biggest impact quickly.

Then you’re building a catalog of things to address and you can prioritize those on each sprint of what’s most important in this cycle to address. That would be my recommendation.

>> AMBER: There is a meetup talk, which maybe Paula can dig up the link for that real quick. There is a meetup talk about how we do ours that might be helpful as far as mapping out those plans. I would also say, come to the goal-setting meetup that I’m going to run in December because we’ll talk about some stuff there. I’m going to wrap this and make this our final question, but there was a question related to estimating and then a question related to pricing accessibility services. Is there anything on that that you can share with us?

>> RON: I think if you’re not familiar yet with estimating accessibility as something for the site, you can start with that 30% number and then work from there. Then as you do more sites, you’ll figure out what that number is based on the complexity of the site, size of the site in your own experience. That’s the best advice I have. There’s unfortunately not a simple blanket answer.

>> AMBER: Take what you normally charge, increase it by at least 30%.

>> RON: [crosstalk]

>> AMBER: Which many advice for agencies and freelancers is always triple your estimate and you’ll be surprised. Then they’ll sign off right away and you’ll be like, “Man, I should charge more for that. This has been a phenomenal presentation. I really appreciate you both coming, sharing your expertise, all the effort that you have put into this website continues to be so apparent to me. We appreciate the support that you have for the accessibility community as well. Can you share where people can get in touch with you both if they want to follow up or how they can learn more about CodeGeek?

>> RON: Yes, I posted our website link, which is codegeek.net in the chat. You can also reach us by email at hello@codegeek.net. We also have a LinkedIn page as well. Any of those would be great ways to reach out to us.

>> AMBER: Thank you both. I’m going to just wait for the transcript to catch up and then we’ll end the webinar. Thank you, everyone, for tuning in and we’ll see you back in a couple of weeks.

>> KEVIN: Thank you, Amber.

>> RON: Thank you, everyone, for being here.

View “Building an Accessible and Highly Usable Transportation Website” Google Slides.