Pub101 for Authors: Accessibility

In this synchronous session of Pub101 for Authors, we welcome speaker Tiffani Tijerina from the University of Arkansas at Little Rock. Drawing on more than a decade of open education work and two award‑winning open books, Tiffani explores accessibility considerations in open publishing, including updated ADA requirements and tips and tricks for using accessibility checkers. Her insight helps attendees understand why accessibility matters and how to apply accessibility practices throughout their workflows. Cindy Gruwell of the University of West Florida hosts the discussion.

Watch the video recording of this April 8, 2026, session or keep reading for a full transcript.

Cindy: So hello and welcome to the Open Education Network's Pub101 for Authors. Thank you for joining us for today's session. My name is Cindy Gruwell and I'm an associate librarian at the University of West Florida. I'm also a member of the Pub101 Committee. I'll be your host and facilitator today.

Soon in just a moment, I will be handing off to Dr. Tijerina from the University of Arkansas at Little Rock, where she teaches technical writing and editing courses. She's also assistant professor of rhetoric and writing. I should have mentioned that first. She has 10 years of experience with open educational resources, including prior work with Affordable Learning Georgia, the Open Education Conference, Southern Regional Education Board, and several grant-funded projects at Kennesaw State University. She has research interests in open pedagogy, instructional design, accessibility, ungrading, and AI and OER. She has two open education award-winning books. Those are Open Technical Communication and Pedagogy Opened: Innovative Theory and Practice.

Here are just a few housekeeping details before we get started. We have an orientation document that includes our schedule and links to session slides and recordings that's already posted in the chat. And we're committed to providing a friendly and welcoming environment for everyone aligned with our community norms. Please join us in creating a constructive base. We've already posted in chat, you should see an opening reflection, a question, and that is, what accommodations do you appreciate in your day-to-day life, subtitles, ramps, large print, voice to text, and anything else you can mention? Please share your responses in the chat. And now I'll hand things over to Dr. Tijerina to talk about accessibility.

Tiffani: Thank you. And I'll just start with my answers to the reflection. I use subtitles for pretty much everything. As long as there are subtitles available, I have them on because I find that it helps me focus on what's being said in the video versus everything else that's going on around me.

Okay, so welcome everyone. You are here, you're in these presentations, you're going to these sessions because you either believe in and already do or are wanting to learn more about open publishing. I think that it's safe to assume that we all agree that a student's zip code or their bank account balance should not dictate their access to knowledge. And I am here to challenge and expand our definition of open, meaning that if a textbook is free to download but can't be read by a student using a screen reader, is it really open? If a video lecture is available to the world but lacks captions for a student who's hard of hearing, have we actually removed the barrier? No. So in the OER movement, we often focus on the legal right to share and the financial ability to buy things, but there is this third pillar, which is the functional ability to use it.

But before we dive in, I have already been introduced, but I'll introduce myself again because I have this slide here. My name is Tiffani Tijerina, and I am an assistant professor of rhetoric and writing at the University of Arkansas at Little Rock. I've been doing open education work for my entire professional career, which is 10 or 11 years now. I've been in just about every role that you might think of in the open education realm, except for a librarian, I have never been that. But I've been an instructor, I've been an author, I've been an instructional designer, a self-publisher, an editor, a grantee, a grant program manager, a consultant, and of course an accessibility expert, which is why I'm here. But my open education work ... Oh, I have a picture too. Sorry, that's there. My open education work started with one big project that is still my pride and passion today, and that is an open textbook called Open Technical Communication.

The first version of this book was originally published as Sexy Technical Communication, and it was a work in progress, and it still is. Over the years, we have the team, because I'm not the only author on this, the team has improved the design, the accessibility, the content, organization, and anything else you can think of on that book. It's been published and republished several times. And that continuous improvement is what won us an Open Education award in the reuse, remix adaptation category, and that was in 2022. And when I say that we're always improving this, I really do mean it. We just published this official second edition of the book last fall after an intensive summer work session. So this is still very much a living project.

And I'm also the editor of Pedagogy Opened: Innovative Theory and Practice, which is an edited collection focused on open pedagogy that was published by the University of North Georgia Press. And I didn't put notes on this, but this also won an award last year. This won an open education award for open pedagogy in 2025.

So I'm going to expand just a little bit on the continuous improvement of Open Technical Communication, particularly the accessibility improvement. And so the first version of the book was, like I said, it was published as Sexy Technical Communication, and there is a lovely story behind that, but it was a working title. I guess to sum it up, that's why it was originally published with that. It was kind of a joking working title that we kind of just stuck with for a while. Students loved it. It was hilarious, but it was originally published using SoftChalk and we chose that platform because our institution had access to it. I was at Kennesaw State University at the time, and the faculty on the team were all familiar with how to use it.

And as far as we knew at the time, it was accessible. We did everything that we knew how to do to make sure that the book was accessible from the start. We included alternative text, we used heading structure, we did all the basics, but we later learned that only about half of our team was actually paying attention to accessibility at the time and so there were a lot of accessibility issues in that first version of it.

And so the first time that we revised it, we did that primarily to give it a more professional look, but also to remedy a lot of that accessibility in the chapters that just weren't up to par. And I don't have a photo ... Man, I keep forgetting to click. This is a picture of the first version, I don't have a photo of the second version, I know it's kind of small there, but it was essentially a webpage where we linked to a bunch of SoftChalk lessons. I don't have a photo of the second time we published it, but essentially we mostly just changed the colors and worked on the accessibility. It looked more or less the same with different colors.

Then we revised the book to have a new name, Open Technical Communication, and that is the name that it has still. And that was intended to go with its new professional look. That version didn't really have a lot of changes beyond the title. But then in 2020, I was hired at Affordable Learning Georgia as program manager, and one of the things that I needed to do in that job was get to know Manifold, because they were one of the pilot organizations for that. And so I took that opportunity to pull Open Technical Communication from SoftChalk and move it into Manifold, where there were so many more accessibility features built into the platform. In addition to the things that we could code into the book, there were also a lot of capabilities in it that allowed students to change the size of the text and change the font style and things like that.

And so at the time, I found it easiest to work with HTML rather than the alternative at the time, which was ingesting Word documents and using HTML with that gave me a lot more flexibility with the accessibility than I would've had just using Word. And that carried over into the second edition that we just published. It's still in Manifold. It's still accessible and we change the colors again because why not?

So with that background, we're going to dig in a little bit. I'll talk more about accessibility in the context of publishing as we go. So when we talk about students with disabilities, it's tempting to picture a student in a wheelchair or maybe with a service dog. And the reason that we picture these students is because they have visible disabilities, but disability is also often invisible. Statistics show that roughly 21% of undergraduate students report having a disability related to hearing, vision, mobility, or cognitive function. And for these students, an inaccessible book isn't just a nuisance, it's a stop sign.

Imagine a student who uses a screen reader when they open a, well, let's say a scanned PDF that hasn't been processed with OCR and then edited for accessibility, their software essentially tells them something along the lines of, "Warning, empty document." To that student, the knowledge that you worked so hard to curate in your class, simply doesn't exist. They can't access it. Or imagine a student with dyslexia who needs to change the font or the background color of a text to reduce that visual stress, but the file format's locked and it won't allow them to make those changes.

When we provide inaccessible materials like this, we are inadvertently asking our most vulnerable students to work twice as hard as their peers just to get to that starting line. We're taxing their cognitive load with technical hurdles instead of academic challenges that we should be, I don't know, taxing them with, I guess. I don't know if that's the right word for it, but ...

And then there's also the curb cut effect. So when sidewalks were first modified with ramps for wheelchair users, engineers may not have realized that they were also helping parents with strollers, travelers with rolling luggage, delivery drivers on bicycles, and workers with heavy carts. Digital accessibility is also a curb cut. When we structure an open textbook correctly, we make it searchable for everyone. When we use high contrast text, we help the student reading on a phone in bright sunlight. When we provide transcripts for podcasts, we help students whose first language isn't English. Accessibility isn't just an add-on for the small minority, though I would argue that that small minority is plenty reason enough to strive for accessibility, but no, accessibility is also, it's a design standard that makes our materials better for all of our students.

Our reflection question asking what kinds of accommodations we enjoy in our everyday life, those are those curb cut effect benefits that we're experiencing. I am not hearing impaired, but accessing subtitles helps me process things without having too many distractions. So much like ... I see people commenting, putting comments in there and I promise I will read them, but I just want to say that I'm not ignoring you. But much like open access removes that financial barrier and accessibility removes the functional ... Sorry. Much like open access removes the financial barrier, accessibility removes the functional barrier. By building for that small minority, we're making it helpful to everyone.

And I see people talking about UDL in the chat. UDL is amazing. I actually didn't talk about this in this presentation. I didn't talk about UDL, but yes, UDL is ... I don't know. I feel like UDL is the best place to start when you're trying to build something with accessibility in mind is to learn about UDL and build that in because it really is a nice comprehensive approach to accessibility.

"Could you explain if Manifold is similar to SoftChalk for OER? Is it preferred and why?" So I would not recommend SoftChalk for OER for a lot of reasons. So the reason we used it with our textbook the first time was, again, it was kind of a tool of convenience. We all knew how to use it and it was available, our institution paid for it, but SoftChalk is a commercial product. It has functionality built in to easily make things openly available, meaning that it's essentially published as a webpage and it has the ability to choose creative commons licenses for the work that you produce in it. But I do much more, I guess, recommend looking at more OER intended programs that such as Pressbooks or Manifold, I think those are two of the more commonly used, Pressbooks much more commonly because it's a lot bigger and a lot more institutions use it, I think.

But I think using those ebook publishing platforms that are designed for OER are going to be a lot more useful than using something like SoftChalk, which was actually, as far as I understand it's designed to be ... It's like a lesson builder. It allows you to build a module, but it's not really intended to publish a whole book in it. We just kind of made it work that way. I hope that answers that question. Are there other questions before we do our little experiment?

Cindy: I think that's it.

Tiffani: Okay. Okay, so we're going to do a little, just a small experiment. I want you to close your eyes for a minute, and I want you to imagine that you're trying to find the chapter on document design in a 300-page textbook on technical writing. You can't see the page. You're listening to a voice that reads every single word from the top of the page. You hear the book title, you hear the author, you hear everything on the copyright page, word for word, you hear everything about the publisher word for word, and it takes about 10 minutes of listening before you even find the table of contents. That is what an unformatted book feels like to a student with a visual impairment. They are relying entirely on what they can hear from their screen reader, and they listen to everything. Christine, "Seriously, you've just described my nightmares." Me too.

And so that is what an unformatted book looks like. You have to sit there and listen for 10 minutes listening to everything that is in there in this book before you even reach the table of contents. So headings are not just formatting, they are essentially a search engine. Kids don't know about trying to find a particular song on a cassette tape. You know that actually, my daughter weirdly does now understand that because she uses a Toniebox. And I don't know if you are familiar if anyone here has kids with Tonieboxes, but it's essentially a cassette tape, like a cassette player for kids where there is no way to choose, you have to tap it a certain way to make it go to the next song. Anyway, we're getting off-topic, but it's interesting that you're talking about the cassette tapes and being able to find the song that you want and sort of the return of weird technologies like that.

Okay. So we're going to move forward because I want to make sure we have time for everything. So we all agree that accessibility is important, right? Well, so does the Department of Justice, finally. For years, digital accessibility and higher education felt like a suggestion or just a best practice, but that changed in 2024 when the Department of Justice updated the ADA Title II regulations to require that all public entities, including colleges and universities, ensure that all digital content complies with web content accessibility guidelines, 2.1 Level AA standards. And some people say WCAG, I tend to just say WCAG. I don't know what most people do, but that's what I usually go with is WCAG.

April 24th, 2026 is the hard deadline for public entities, such as our institutions, to meet those standards. And this is no longer the vague good faith effort that we've always sort of been told to follow. This is now a specific technical checklist. If the course materials, including PDFs, slide decks, interactive resources, textbooks, if they don't meet those standards, then the institution is in a state of non-compliance. And that's why everyone's panicking, is because this deadline's coming up fast and institutions are really concerned about whether all of the resources are meeting those standards.

And this is important. The law explicitly also includes third party content. So that means that if you adopt an open textbook that was created by someone at another university, you and your institution are responsible for its accessibility the minute you assign it to your students. We can't delegate away those legal obligations, and that makes our roles as creators and curators of open content more important than ever because we are sort of that first line of defense. Before you assign anything to your students, even if you didn't create it, you need to make sure it's accessible.

So breaking it down. So WCAG, like I said, stands for Web Content Accessibility Guidelines. It's a set of rules for digital accessibility. 2.1 is the version that we're on, and that's the version that is required for Title II. And AA is the level of compliance required for Title II. And there are actually three levels of compliance. So Level A is basic, very bare minimum compliance, and it's not considered sufficient to satisfy Title II. Again, AA is the required level that makes sure that, it ensures accessibility for most assistive technologies, and that's the baseline level that we are expected to meet. And then AAA is the highest standard. And while it's not required by Title II, we should strive for it anyway.

WCAG is rooted in four main principles or the acronym POUR. So perceivable, information has to be perceivable to people using only one of their senses so that they understand all related content. So whether it's using their eyes, their ears, they have to be able to perceive that information or with their hands too, there has to be a way for them to perceive the information with using just one of their senses.

Operable, end users need to be able to interact with all elements of the page. So any kind of interaction that's built into your resources, if you decide to publish something with interactive resources in them, those resources also need to be accessible.

Understandable, so users need to be able to understand content and functionality of information. So that's thinking about the cognitive load and additional unnecessary information that might be added in that might distract from the purpose of the content.

And then robust. So the book needs to effectively communicate information to all users, including users of assistive technologies and remain compatible with evolving technologies and user needs. So that doesn't mean that we have to anticipate what future technologies require, but it does mean that it needs to be something that can be revised or fixed as needed as technologies evolve.

And if you want to get really crazy, you can read what WCAG 2.1 for yourself. This QR code will take you there, or I can also ... Let me see if I can copy this link and put it in the chat for you. I'm going to talk about the most common stuff in just a minute, but if you want to go and learn everything you ever wanted to know about WCAG 2.1 expectations, then you can go and do that.

Let's see. We have a chat here. Yeah, so Ally is a very useful tool to help with checking for accessibility. The one thing I like to tell people is that there are tons of really useful accessibility checkers out there. Your best bet is to use them, but not rely on them entirely. You want to make sure that you also are doing everything you can to make things accessible because the checkers are not always going to catch everything. Sometimes they flag things that are not actually a problem, and sometimes they miss things that are, just like any technology. I mean, even Microsoft Word gets grammar wrong sometimes. So yeah, relying on those checkers ... Using those checkers, awesome. Try not to rely entirely on them though.

Okay. This is my pause break. So take a breath. I've been talking for a while. Process for a minute, put questions in the chat if you have any. If there's anything you'd like me to clarify before we start talking about the four common accessibility failures, which is my next thing.

Okay. Karen says that, "There will also be time for Q&A at the end that's not part of the recording." So if you would rather wait until then, that's fine too.

Okay. So four common accessibility failures. So when we look at document accessibility, a huge chunk of our accessibility debt comes from four areas, and this is specifically looking at document accessibility. So there are also the multimedia accessibility concerns, but since we're talking about publishing open textbooks, we're going to focus a little bit more at the document level. And so like I said, a huge chunk of our accessibility debt comes from four areas, and that is heading hierarchy, alternative text, color use, and scanned PDFs. And the scanned PDFs has sort of its own little caveat because in general, I just try to avoid PDF as much as you can when it comes to publishing in the first place, but sometimes it's unavoidable to include them. So we'll talk about that in a minute though. But let's look at each of these and how to fix each of them during the authoring process rather than having to retrofit later.

So heading hierarchy, often people will use bold or larger fonts to indicate the start of a new section in documents. It's common to type your document out and then say, "Okay, this is my heading. I want to highlight it. I'm going to make it bold and I'm going to bump up the font size a little bit." That's common and a lot of people do it, but to a screen reader, that just reads it as bold text. A screen reader doesn't read the size of the font and it doesn't tell them the significance of that line of text. It doesn't tell them that this is the heading to a new section.

So to fix that, we use heading hierarchy. This will look different depending on the platform that you're authoring in, but in basic word processors such as Microsoft Word or Google Docs, you're going to look for what's called the styled panel, where you can change from normal text to heading one. And you can do this anywhere. Even if you're working in something other than a word processor, I can almost promise you that the functionality is there. You just need to find it. Most authoring platforms are going to have this heading hierarchy functionality built into it. If you're working with HTML, you would use an H1 tag for heading one anyway, or H2 for heading two, et cetera. Pressbooks and Manifold also both have this heading structure functionality in them as well. And I can't really show you how to do it in every single platform, but like I said, I almost promise that it's there. I'm not going to say 100% that I promise, but it probably is there and you just need to find it.

But with heading structure, there are two really important rules to keep in mind. So first heading numbers, the H1, H2, et cetera, those are for nesting, not for counting. So we don't count our headings where the first heading is H1 and the next one's H2, the next one's H3. We're actually going to nest them. So if the first heading is H1, then the next heading of the same level should also be H1. But if there are subheadings in that H1, like if there are subheadings under that first, like you have a first heading and then you're like, "Okay, within this heading, we have these other subheadings," those would be H2. And so we're going to nest them rather than count them. I hope that makes sense.

And then the second rule is that you shouldn't skip levels. If you skip levels, it creates kind of a confusing navigation structure that increases that cognitive load on the user using a screen reader. It makes it harder for them to follow and keep track of where they're at in the document. Sorry if I start losing my voice. I don't talk this long very often.

All right. Okay, meaningful alternative text. So this is where we add text to the code of an image for the screen reader to read. So remember, someone using a screen reader might not actually be able to see the images that you're including with their eyes. So it's important that those images have an alternative description that is It is as close to equivalent as possible in information. So we want to make sure that we don't just describe what the image is, but also what it does. For example, a bar chart with alt text that just says, "Bar chart," isn't helpful to the reader, but alt text that says, "Bar chart showing a 20% increase in global temperatures since 1990," is much more helpful and tells the reader what they actually need to get out of the image.

So if you're putting an image in your book that gives them information that they need, you want to describe what that information is. And if an image is purely decorative with no true function on the page, then there's usually a place where you can mark that and say, "This is decorative. It's not important. The screen reader doesn't need to read it." And you can do that.

We have a question, so I'm going to pause here real fast. "What do you mean by do not skip levels? Give us an example." Yeah. Sorry, so the next comment after that says, "Don't jump from H3 to H5," for example. Make sure that you have an H4 before having an H5 nested in it," and that's exactly right. So skipping levels, I wish I had a picture of what it would look like if we were sort of jumping around on levels, but if you take a Word document and put in a bunch of headings at different levels and then open up the ... You can have it create a table of contents and you can kind of see how it staggers weirdly.

The weird staggering looks weird to us and it looks just as weird to someone using a screen reader. It's hard to follow. It's hard to figure out what level heading, where certain things belong. Is this a subheading of this one or is it a subheading of this one? It kind of creates that confusion there. And so having them properly nested and not skipping levels like that is what helps them keep things in order the way that they need to be. I hope that helps, hope that makes sense.

Okay. So color. Using color as information is an accessibility trap. So sometimes we see things that say like, "Click the green button to start." Or, "Errors are highlighted in red." And there's not really a problem with using color in those cases, the problem is when color is the only indicator. So color should never be the only way to convey meaning. You can use color with symbols such as a green check mark, or you could use color and text, meaning where you might combine a green button that says start on it, or color and emphasis such as a red caution statement that is also boldfaced, but combining those things creates something else that is conveying that meaning.

So if you have a red caution statement, if it's just a red caution statement, that redness is not conveyed to the reader, but if you bold face it, then the bold is conveyed through the screen reader. It'll say, "Hey, this caution word says bold, or is bolded," if that makes sense. And so color is not read by a screen reader. That's the important piece is that when you use color on text, the screen reader does not tell anyone that. It doesn't tell them the color, it doesn't tell them the font size or the font style and so making sure that you have something else to convey that meaning is what's important.

And then you also want to make sure that you check your color contrast when you're using color. For example, light gray text on a white background, that is an accessibility nightmare to anyone using it. It's really hard to read light gray text on a white background. And so making sure that there's some good color contrast, black on white or really dark letters on really light backgrounds, that's going to make things a lot easier to read.

Okay. So we have an example in the chat about, I am not going to try to pronounce that, I'm sorry, but a type of colorblindness and the way that using color to indicate meaning can impact someone who has colorblindness. Colorblindness actually runs in my family. I do not have it, but my grandpa does, and I think a couple of my uncles do as well. And I know that making sure that something else can show them that meaning is a lot more useful than ... "Women are carriers, men are sufferers." Okay, I didn't know that actually, but that's good to know. But yeah, having something else to indicate that is helpful, not just with a screen order, but also for people with colorblindness.

If I create an accessible Word document and save it as a PDF, does any further remediation need to be done to the PDF? Probably, because not everything transfers perfectly into PDF format, but it's something that you would just want to check. You may not need to fix anything, but you probably will have to fix one or two things. I think the most common thing that needs to be fixed with when you're converting from Word to PDF is the title of the document. I think that doesn't typically transfer over as well, or at least it didn't in the past. It's been a while since I've done that, but yeah, it's worth checking either way. We're going to talk about PDF in just a second, actually.

This is my little zombie. And finally, scanned PDFs. So a scanned PDF, especially if you're, like I said, scanned PDF, meaning that you took something from a book and stuck it on a scanner, turned it into a PDF, and did nothing else to it. A scanned PDF is essentially just a photo of words. So it can't be searched. It can't be read by the software. It can't be resized for small screens. It's essentially an empty document from an accessibility standpoint, which is why we call it a zombie document. It's there. It looks alive, but it's empty.

So if you can't highlight the text in your PDF, it's not accessible. And there's more to it than that, but that's bare minimum accessibility of PDFs. And so to fix that, you can use OCR, or Optical Character Recognition to convert it to a readable document. That does not make it fully accessible, but it at least makes it less empty. But in general, I really do. I prefer to tell people to just try to avoid PDFs altogether because remember, there's more to it than just making a basic accessible document. There are also things like allowing students to change the font to reduce their cognitive load. They can't do that in a PDF. They can do that in Word. And so there are a lot of things that PDFs kind of lock down beyond just that basic accessibility piece.

So if you can, move your content to a ... So Word is probably the most common of everything, but as far as publishing a book goes, you should try to move your content to a more web-based format like EPUB 3 or HTML, formats like that that are born accessible. They create a lot more capability for accessibility. There's a lot more flexibility built into them.

And Christine says, "For example, your local library may use scanned PDFs for course reserves and online courses." Yes, that is very, very common. And also sometimes very frustrating to find scanned PDFs in the library that we need to convert. And that's probably something that your library is working on.

Let's see, "In the old days, we were taught to use PDFs over Word because everyone can read a PDF and not everyone had Microsoft Word." Yeah, so Microsoft Word or Google Docs, those are much more available now. Your students have access to it. I think it's probably safe to assume that most, if not all, at least public institutions have access to Microsoft, but if they don't, Google Docs is also there and available and can read Word documents. And so it's a lot more available now, which is why that concern of people not being able to access Word documents is not really as much of an issue. There's a lot more functionality in Word documents that students can use to manipulate and make things a little bit easier for them to read that they can't do in a PDF.

Christine says, "Libraries are panicking because they need to change plans. Everyone's panicking. You're not alone."

And yeah, so Karen says, "If you can, it's great to offer more than one file type." Absolutely. So you could share both a Word document and a PDF, and I do that. So for my textbooks, let's see, so for the last version of the first edition of Open Technical Communication, that one had the ability to download as a Word document, as a PDF, as HTML files. I think we have EPUB 3 up there, but I'm not 100% sure. And then we also had a print version created that students could purchase at cost. The second edition, we have not gotten that far yet. I think right now we just have Word and PDF, but the plan is to build up those file types and have all of those options available again.

So yeah, you could offer the Word document in the PDF and you can, if you're using Pressbooks and Manifold also, both of those have the ability to create multiple file types. So for example, we actually created our EPUB 3 version of the textbook by having Manifold generate it for us. And so yeah, there's definitely those capabilities.

And that is actually, that's my last slide. So, well, this is my last slide. Final thoughts, don't try to fix everything that you've ever created this afternoon. Start with one thing and then just keep making progress. Work on one thing, make progress to the next and keep going. Accessibility is not something that you start and finish. It's a standard of excellence that we're always striving for. You might always have to revise things a little bit as technology changes, and that is okay. The more accessible your content is now, the easier it's going to be to adjust it as technology changes in the future.

But for new development, build that accessibility in as you go, be proactive about it. And then for things that you have already created, if you've already started on your work, it's okay to kind of just take it step by step as you work to improve that accessibility. That's what I got. Thank you. That's me.

Cindy: All right. Well, thank you. You've answered quite a few questions along the way here.

Tiffani: Sometimes it's hard to decide how much to include and how much to condense into a session like this, but I'm happy to answer questions now or through email. I'm happy to help in whatever way I can.



END OF VIDEO