 Welcome everyone to the reading systems panel. I'm going to be your moderator today. My name is Wendy Reed and I'm from Rakuten Kobo. And today we have four excellent panelists who are here to represent various reading systems, but also user perspectives as reading system users. We're going to have, I'm going to see if I can try and keep us to about 35 minutes so that we have time for about 10 minutes for questions. If you have a question, feel throughout the session feel free to put it in the chat if you don't want to forget it. Otherwise save it to the end and we'll do no hands up method. If we run out of time for questions, we are, we do have a channel in Slack, I will put the name of it in the chat, but there is a chat in Slack so if we happen to run out of time for questions, go to that channel, feel free to post them there and we'll find time to answer them. And I think that's it for housekeeping. Let's get started. Now we start with introductions. I'm going to start in order of who I can see. Rick, can you introduce yourself. Hello Rick Johnson with vital source. Thank you, Rick, and Lars. Hey, I'm Lars, I'm product manager, etc, etc at Columbia software in Gothenburg, Sweden. And Daniel. Hey, everybody. Well, tonight I'm mostly representing EDR lab, the European digital reading lab. But I have also worked for a very long time with the Daisy consortium and the region foundation. I'm a software developer. And I'm based in the UK. Awesome. And Simon. I'm Simon I'm working as an accessibility tester for Nels. And I'm based in Western Canada. I'm using all right. So we have an excellent panel as you can all see here today. I'm just going to launch directly into the questions. And my method is, if someone doesn't answer in the first like five seconds I'm just going to call on you so be prepared. So for our first question today. What advances and developments are happening with reading systems with respect to accessibility. I'm going to start with you Lars. I know you've been working hard. Yeah, I've been, I've been working hard. I actually published something just like 15 or 20 minutes ago. So yeah. I would say that I mean all the reading systems on the markets are developing really quickly I think it's it's fascinating to see. I love the work that Daniel is doing with orium and Rick I'm sorry I don't use vital source that much but I've heard very good things. And we of course I've been spending I would say the last 12 months just trying to, to really push this and make things, you know, better and better and more intuitive and speak to more disabled users or not so disabled users maybe. So, no, I think it's, it's, it's looking good. There's much work to be done and I think I invite all, all us developers to join and try to to talk more amongst us, maybe put together some kind of working group or something and start streamline streamlining our feature sets and making it easier for for producers to produce books that look fabulous and work fabulous across all reading systems. I think that is super important. But so yeah so just to give a recap, our first question is about advances and developments, what advances and developments are happening with reading systems with respect to accessibility. Why don't we go to Daniel. What's up in thorium land. Well let's say there's a definite convergence a continued convergence tools. Web technologies. So tonight I'll be talking and sharing my insights from from the perspective of thorium which is a desktop app for Windows Linux and Mac so it's not a web app it's not a website. It is built with web technologies HTML CSS JavaScript. So we use the exact same W3C guidelines that you'd be using if you were developing a website I know Colibrio here represented by Lars. They have a fantastic web reader that implements accessibility features based on existing W3C recommendations such as WCAG web accessibility initiative content authoring guidelines. I think that's the one and only time I'll be spelling out this acronym area for semantic roles and adding accessibility features to HTML documents. There's definitely a very productive technology stack that that makes it possible for us in thorium to to improve our level of accessibility. Awesome. And Rick. I think there's two really exciting things happening right now around reading systems and accessibility and they were touched on already but it's the first is, it's assumed now I'm, I'm 30 years in this industry. And it used to be always a specialty case. It was a it was a one off it was a go here to do this for accessibility. It's assumed you have to have it to participate and that's a wonderful thing that has happened and the reason it can be assumed now is the other thing happening and that is standards that we have gone from 20 30 years ago when everyone was always saying so why isn't, you know, fill in the blank, doing the right thing with whatever area that they were worried about. We've got a great specification for file formats. We've got a great specification in any pub around. How can we do accessibility there. We've got checkers that can check it we've got authoring systems that can create it. There's a lot of these last mile things that we're getting done because of interoperable specifications and it's exciting to think about where we can go. Like like Lars talked about in terms of even feature sets starting to become interoperable and in exchanges of information in the future so it's to me just very exciting, very affirming for all the work that people have done over the years to get us to this point. Yeah. All right. I guess the second the next question. What are reading systems or retailers doing to ensure content, the content they display or ingest is accessible. I think I'm going to go to you, Rick first actually. I'm going to go to you in our session here but probably need to go to the metadata session because that's the biggest thing I think is letting people know what's in it before they buy it, how does it going to work with your application was your application reading system do all this information that they need to know before that when they're discovering it when they're an instructor and they're requiring it for their course or if they're a user and they're buying it or if it's trade title and they want to read it. The metadata is so critical and so key, and then understanding not just metadata about the content but about the app and sort of what the capabilities are that's just being transparent about that is the most important thing. Due to push against publishers that are providing PDF. I was just in communication with with an author and publisher, and they had both a PDF and an e pub version, and only the PDF version was available on vital source and I screamed at them for that and I thought they fixed it but what do you do to, you know, say, you know, do you really want to provide us with a PDF. Well, the key in that scenario for us is the consumer and the institution holds the keys there because they know they need an accessible format for their users for for their students for their learners. They know they need accessible format for legal issues and for compliance, and they have the strength to be able to push back stronger so we encourage the delivery that we encourage getting that we have started actually doing what I would call public shaming. If they're not in our metadata if they don't provide us with metadata we say hey talk to the publisher because we don't have any metadata about the accessibility of this file. We're encouraging that through through the means we can through contacting them, but the people who are out there, the consumers who are out there purchasing they held the keys because it's it's all about finances from the publishers and providing that into the marketplace. I'll jump in here too because I think this is also a space where people like retailers, or ingestion streams can be opinionated. A couple years ago we just stopped ingesting PDFs. We said we're not selling them anymore. You know, providing the reading systems to to provide them as a pain. It was to support continue supporting PDF but it also just they weren't selling well and they weren't achieving the content goals that we wanted so we just stopped accepting them, and that seems to work pretty well at least so far. Lars or Daniel I don't know if you have any thoughts on this too. Sure. Sorry. No, go ahead. I forgot the question, but I had an answer. Wendy, please remind me. Reading systems and retailers what are you doing to ensure content that. Yes, or injustice accessible. I'm getting old. Okay. So what I wanted to say was that, of course, being a framework. The plan has been since the get go pretty much to to break apart the content as much as possible and expose as much data about the content as possible through the API is that we offer. So, what I am planning to, to kind of like evangelize to our customers is to use the API is to actually, even if there are, even if there is no, you know, accessibility metadata, you can still using our API is go through the the content and and give people heads up. If, if you find that there are missing, you know, missing semantics in the document, for example, or whatnot. So I think that I hate being pragmatic but sometimes you know you just need to, to get things working right. And while we wait for proper accessibility metadata, I think it's, it's good if, if the reading systems can expose, you know, obvious flaws in publications to to the user, you know, as an interim solution. And so that I think would be a good thing if. And I also have my accessibility annotations initiative that I always mentioned, which would be a cooperation between us three Daniel and Rick and us so we could share accessibility metadata cross systems. So, yeah, let's talk more about that. Let's talk about your friends, even better friends. That's all. Thank you. Daniel. Well, from my experience in the thorium project. Thorium started out as a, an EPER reading system. We knew we were going to add support for Daisy digital talking books as well which we did. We also added support for audio book formats and, and comic book formats. Ironically, we also added support for EPER for PDF. Not because we claim to offer a better reading experience than say your default reader on Mac, which is called preview or acrobat on Windows, whichever, but just because PDF is ubiquitous and we just needed to support it. So we're going to be taking off the shelf component PDF JS for JavaScript so it's the same component that you'd be using on the website to render PDFs. And, and that's what we do anyway so that that was a side note, going back to content production. So I'm not an expert in anything really and but I'm certainly not an expert when it comes to content production. My perspective is really from the reading system and. I'm not an expert in any of the things that I've mentioned here and I'll say my experience is that it's a bit like a dance a bit like tango between the content that we have to ingest in the reading system and what we implement as as reading system developers to make that work. There's a push pull sort of passionate dance between these two sometimes conflicting ends of the spectrum. There's a factor in that dance, and usually, which makes things even more complicated that's a screen reader and other assistive technology that sort of insert itself between the user experience, the end user let's say and, and the content and that that's what creates as a whole the user experience. So at times it's a very frustrating experience, but it's also very rewarding when we find ways to make it work. So that was my side tangent. You know what it's a great tangent because my next question is going to be about assistive technology. So, what, and I'm going to loop Simon in on this because we haven't heard from him yet, but Simon accessibility tester and I know he's a reader. What are you, what are you looking for in a reading system. Do you look for specific features depending on the content that you're reading. What are some of the bad experiences and you know when it comes to assistive technology, how do you look for it to work with products. Well, my answer depends somewhat heavily on what platform I'm using. So, on my phone. It's, for instance, very inconvenient to use a reading system that does not have a read aloud feature because my screen stays unlocked. I don't necessarily want to read aloud feature on Windows desktop, because I can just use my screen reader say all command. In general, though, I think it boils down to, I'm looking for simplicity. I would like the features that I need the basic features of the reading system to be accessible in a way that makes it fairly apparent how to get there. In the user perspectives panel but one of the reading systems that I use for the longest on Windows was just a giant text box with a couple of keyboard shortcuts for jumping between headings and jumping to bookmarks and table of contents and such. And it does not. I don't even know but properly supports EPUB three. So there's definitely some downsides, but for a while that was perfect because it was just the simplest thing on the planet. I do find that there is a trend towards web technologies now which is good because the bare minimum is still more accessible than the bare minimum using most other UI toolkits. So that's good. I think in terms of bad experiences. The only really bad experiences I've had aren't applicable anymore. There were some reading systems that basically by way of DRM forced you to use them and nothing else to read certain content and they weren't accessible. That seems to be changing, which is great. Libby, I'll call them out have become much more accessible over the last couple of years. Kindle used to be pretty broken in the early 2010s and maybe even mid and that's much better now. Sorry, was there another part to this. No, there was not that was perfect. I guess to flip it around to the reading system perspective, you know, what do you do to ensure that assistive technologies and the users who use them are having good experiences with your apps. We do a lot of work in that area. I mentioned earlier that it's it's assumed now to have accessibility. It's required vital source every development team is is annually trained. We have third parties that come in and hold our feet to the fire to make sure we're doing it right and review us and independently work with our teams and their stand-ups and writing bugs into JIRA and making sure that we're doing what we say that we're doing and claim that we're doing. And then even down to code reviews and development teams will turn off the screen as we're going through a code review to make sure that things are working right with screen readers and that developers understand the issues that are going on. We'll work with accessible teams at our institutions with the DSO offices or students that have different accommodations and make sure that we hear from the end users and work with them. It's an ongoing, never-ending journey that you don't ever arrive at, but you have to continue down the path and continue doing it. Lars? Yeah, I've been working so much. Basically, we are a small team, right? Just as Daniel, I guess you also, I mean, you work at Desi, you know all this, but it's important to understand, I think, from a user's point of view and especially if you're an organization that is planning to build or implement a reading system that is fully accessible. That accessibility, I don't care how much people tweet about accessibility just being about using semantic HTML and whatnot. Accessibility, because of what Daniel spoke of, because of the very, very varied implementations of the accessibility technologies. Implementing good accessibility that is stable across all accessibility technologies is really freaking hard and it's going to make your budget for the project. There's a lot to do with properly, especially if it's your first project, it's going to be times two. The time it will take to implement the user interface and stuff. And you just need to accept that. So that is an important point. People don't want to talk about that, but it's a super important point to not undersell the difficulty. And I mean, it's not just up to the developers of reading systems. Reading systems are hybrid technologies. So, and there are real limitations for reasons in, you know, we as developers of hybrid technologies do not have, and actually of web technologies basically, we don't have the same luxuries as the native developer would have, because a native developer can can listen for, you know, the, the behavior of the accessibility technologies and follow them around the user interface and know exactly where they are and what they're doing and stuff. But in web land, that that is not a thing. You never know what the screen reader is doing so. And for a reading system that is darn, you know, it's very inconvenient, let's say that you never know where the accessibility focus on the screen reader is that makes life really freaking hard. Daniel, tell them all about this pain. Because we need a web API to fix it. Yes, the inconvenient truth of accessible web development. Look, you've both already said many important and interesting things. So what I'll add is I'm one half of the thorium development team. We're very small as well. And I'm cited for those of you who don't know me. And my colleague is also cited. So we don't have the expertise with screen readers. And we rely on external contributions testers who are willing to give a go and engage in a feedback loop with us. I would say in terms of cost to add to what last already described documentation is also very important points that we as developers tend to be very bad at documenting things other than, you know, we see technical documentation. I'm talking about and user documentation here. So we do maintain, you know, like a reference for our keyboard shortcuts and but there's so much more we need to really make the app accessible. You know, the first point of entry is not necessarily trial and error with the app. It's reading a couple of paragraphs or pages of documentation just to figure out what the application is all about and how it works. Awesome. I'm going to jump in here too, because I'm really jealous of my fellow panelists because they're a little bit further ahead than I am or we are at Kobo in this process but I'll say because we're a little bit further behind. I've gotten to take a slightly different approach where we have leaned pretty heavily into testing with people with lived experience. So we've engaged companies like fable where fingers crossed we're going to get to start working with Daisy and mel soon as well. To start understanding what users of our platform are going to want to do with our, our apps and our reader and our readers and then work from there, because we want to understand what people want to do we want to facilitate all of that, while obviously ensuring that our reader continues to work and is accessible to everyone. And the other thing, the other, I would say an interesting challenge for us as well is because we produce an ink device devices pose a slightly different challenge in terms of accessibility because we write the software for those. We are not relying on existing frameworks we have to, you know, kind of build our own and up until recently some of our devices didn't even have audio. We recently added blue tape which is going to open a door, but also a whole new adventure in terms of making those accessible because NVDA is, you know, not an installable application on our devices. But I also would add like the other important part is to consider the needs of the user. First, especially when it comes to like we don't want to try and interface with assistive technology by like trying to figure out what they're using or trying to like, we want it to work without knowing any of that information and we should just be testing as broadly as possible to ensure that, you know, we're respecting user privacy and user needs and we're not, you know, we're not trying to guess at anything, we're just making sure that it works. I'm going to go to the next question, which is. I think this is going to be maybe an audience favorite. How do reading systems determine the priority of building features or fixing issues. And I'm going to go to Daniel first. You know, coins, either pound coins in my country or euros in Paris, depending on which side it lands on with this. No, of course not. We have a book triage process and especially at this stage of the project, thorium is becoming more mature now. We are really trying to prioritize things based on user needs. We have some great feedback and some really exciting features that people are requesting, but we just we just can't do it, you know, on our own, and it's an open source project, of course, so as, as all open source projects, it's one thing to say that it is open source but the main challenge is to onboard people with technical skills to help with translations, you know, localization with adding features with extensibility, all that stuff. So, yeah, I look forward to hearing from Lars Riggs and others. I'll stop here. I'll go to Rick next and unmute. Okay, we, we hold focus groups with our users quarterly to make sure that we're hearing from them. If we're doing the kinds of things that things are working the way they want if there's issues that they're having. And also to test future prototypes of features that we're looking to bring out and so we're trying to always hear that voice to customer. Our customer success team and our, and our publisher relationship teams also work directly with our customers to make sure if there are issues that they get escalated quickly. A great example. Last week we heard very quickly, start of a semester, there was an issue with math rendering in a number of different books that turned out, given a certain order of events that the software we were using to render math ML called math checks had an issue that they had just fixed. It went to the top of our list and within six hours we had new versions of our apps out and updated to make sure that we incorporated that latest fix from them so things can bump up things can get prioritized if they're stopping learning from happening or if there's an error happening or if there's something critical out there. But other than that it's a fairly regular voice of the customer to make sure we hear what the right things we should be doing. Awesome. Lars. Well, since we are a framework. You know, if you look at the demo readers that I, you know, smack together. Those are just implementations to help companies around the world and schools and governments and whatnot build accessible and nice reading systems. So we have a different stance we move slower, because we implement standards, the only thing we do basically we never come up with something. We, we make sure that we implement the API's, you know, as closely as possible to the standard to the standards, anybody who knows me will say, you know, know that I'm very bullish about, you know, following standards. So in our case, because of that, I don't think we have that many bugs per se. And when it comes to features, we are very careful because of many, many, many people around around the world kind of rely on our software being very stable. So, but of course, once in a while their pops, especially I think we are need to fix the ad stuff to be more forgiving. I can for example say that we have had I must and I'm very super happy about this so many new media overlays books. And in some cases, because it's a new thing right so people start producing media overlays, where they have almost overlapping, you know, boundaries between the segments, audio segments so in many cases we, it's, it's more about us needing to, to see where we can implement, you know, where in the stack of API's we can implement lenience, is that a word, so that we are more so that we are friendly to the, to the, to the developer and also to the end users so that they don't. We fail gracefully as they say we are down gracefully. So that's the thing we do but otherwise we, we just make sure that everything is super stable. And again, if it, if it's in the standard, it's in the API's that will be that's what we strive for. If you want to build a reading system, you will not need to ask if it's supported by Columbia we will try to make our best effort at, you know, following and implementing the standards. Cool. Um, I guess I'll say it's interesting that we have so many different types of reading systems here so like from the retail perspective, most of our like feature and issue driven questions kind of come from. Just to say this financial impact. Um, you know, how the scale of the bug can be books don't load, and if books don't load, then we have a really big problem and we've got to fix it immediately but when we're looking at things like features we're often looking at areas that we want to focus in on so for the last couple years for instance if you've used Kobo you've probably noticed that we've gotten really into nonfiction reading and, but, and features related to nonfiction reading so releasing devices with styluses or improving our navigation capabilities, so that you can, you know, shipped back and forth in an ebook really quickly. And focusing on features like that because that was what nonfiction readers wanted, but it also had it. Every time we implement a feature like that we want to see does it have a cascade effect to other types of content and which most the time it often does. I mean accessibility, I always try to look for the accessibility angle and just about any feature we try to implement because oftentimes we work on a goals based system where instead of saying oh we want to set we want to, you know, add text to speech. The actual thing we're asking is we, how do we make people want to read more books. Well, one of the ways might be to add something like text to speech or to, you know, there's a number of different ways you can do this and my, my role is always to see, okay well what's the accessibility angle, you know, is there a feature that we can add, or a thing that we can add to this feature to make it more accessible and, you know, raise the profile of our, of our products and make it people happier and then for issues it's just impact pure impact, you know, how many users this impact, how bad is it, things like that. George we're going to do questions in five minutes, just a heads up, but then we're going to, we have a couple, a couple more questions. I think we kind of, we've already touched on priority and things so I want to ask, because we only have five minutes left. So this is the dream question. And it is, what does an ideal reading system look like. What could they be, and how far away are we from that vision. And I want to start with Simon. So, I don't know that I have a single dream reading system, but it tends to be that reading systems will have some features but not others, like, they will have amazing navigation and amazing features, but it will only read a page at a time, and so forth. I did think about this quite a lot and I don't know if I have a dream reading system in mind. But ideally, I would like to see more reading systems that support accessibility metadata, and more that maybe support automatic features like OCR of things that need it. That sounds cool. Daniel. You could unpack that question and expand for a few minutes. So I'll keep it short. I published a link to a Google doc in the Slack hash reading dash systems. I can post it in the chat here as well later on. This is my notepad. I jotted down a few notes for this meeting and it sort of lists a bunch of features in thorium that relate to accessibility and usability and I, you know, clearly we completely agree with Simon. We have to look at the feature set and make sure it's, you know, depending on your, on the type of user, you'll have different needs so we could debate on what's important or not. But for me, a reading system really should be sort of transparent, you know, non intrusive. It should be just there. You know, you double click on the file or if you're on a platform that doesn't have a file system like a tablet, it just happens, you know, it's a performance is a very important point to, to, and I, you know, I think we can do better in thorium, but we are at the mercy of the stack, the technology stack that we're using in thorium, which is inherently slower than native technology. So there's only so much we can do. There's a compromise there. But for me, you know, with the DR lab, we put a lot of focus on accessibility. So this is clearly something we're passionate about. So whenever we have positive feedback, we take that as encouragement and it hurts when we have negative feedback. But we, as I think Rick said earlier on, it's a constant of efforts, a continued effort to get it right. And you never really get there because, because technologies advance, right. And you need to keep up with, with the operating systems updates with the updates of screen readers themselves. The web platform can continuously evolves as well. For example, thorium is built with web technologies as I said earlier on HTML CSS and JavaScript. But it's also built on top of a particular web browser engine called chromium, which powers Microsoft's own edge web browser. It's also in Google Chrome web browser and many others. So, you know, if chromium doesn't implement a feature that we need, such as MathML will be using math jacks just like vital sources reader to display accessible MathML. And I could carry on like that with many other features that we depend on. Yeah, so that's it. Rick. So to me the ideal reading system and I'm going to, I mean, vital sources works in the education training learning environment and so from that perspective. Daniel touched on it I think perfectly it's it one that disappears it gets out of the way as a learner, I need to get into the environment that I'm learning I need to be able to interact with it I need to be able to test my knowledge I need to be able to understand where I need to review and move on and the reading system should be a part of that process it shouldn't be a step in it it should just be invisible and facilitate my access to that information. Whether I'm cited whether I'm have other disabilities mobility issues for whatever my, my issues or my accommodations are that I need to be, it should just disappear and be be gone that's that's my ideal. Okay, and we're almost running out of time so Lars really fast, really fast. I just want to I read a lot of fantasy and sci fi and comic books and whatnot. And to be honest, I want to see said you said people here I, I wanted to kind of get out of the way but I also wanted to augment my reading experience when I wanted to. I want to I've always said that I want an API for a book where I can basically ask questions to to ask my reading system questions and it will help me with reminding me who a character is or find stuff in the book. I think we're getting closer to this this is something that I will be into a lot in the coming years, a natural language processing and stuff to be able to talk to my reading system. I want it, I want it now. Yes, I just want the I just want the reading system that Simon wants and Melissa yesterday spoke about wanting just some one place where you could read anything, however she wanted. That's my dream reading system. And let's get into, let's get into questions. George you raise your hand first so I think you get to ask the first question. Is E pub test or helping you. What should we do more. And for those of you that don't know about it we do at E pub test org. We have test books and we report on various reading systems. Most of the developers here are familiar with us, but how are we doing what what can we do to improve it I've got a reading system agenda I have to send out for this coming Tuesday at noon at 11 Eastern so and all of the people here are welcome to join us in those meetings. I actually have an answer for you George, because I was just looking at you put us at work with a coworker the other day. And the one question we had was, it was, we use the E pubs. It was great to see what supported and how well. But I think more user experience feedback would be helpful when interacting with these very specific components or these navigational elements. What did the user like, or not like about this particular reading system, reading systems behavior with this document, because the documents are good. It's good to know that these features are supported or, you know, not supported. But, you know, did they want something more from it like it's great that it passed, but was it a good experience or was it. How many backflips did you have. Yeah, exactly. Exactly. Okay. I don't know if Lars or Rick or Daniel. They use the publications from the E pub test suite and the Daisy test suite as well. They're very important publications, straight to the point. They distill a few problems down to their essence and and we're able to test features with an hour of focus but I completely agree with Wendy about user feedback and I will also say, and the onus really is on us as reading system developers to find opportunities of publications that will, for example, stress test a reading system in terms of performance. Just an anecdote. We support Daisy digital public talking books, which tend to have a very large DT book XML documents in the case of Daisy three, and that's a definite killer for for an app like throwing that wasn't designed to handle huge problems. So those are the fun things that we have to deal with, but the onus is on us to to find other relevant sources of publications. All right, I think it's a good, it's a good point though, just quickly that we maybe and this this is why I was arguing for like a working group with where all the reading system developers and vendors get together and share publications and testing strategies. Maybe we need a CG. That might be what we need. I believe I saw Melissa first on the question queue. So that's nice to go. Yeah, thank you everyone. It's actually really fascinating and like I'm so happy to be listening to the reading system perspective and actually there's quite a lot of overlap with the panel about digital literacy and I will actually be talking a lot about the reading system. I guess I have one of the question which is not really like well formulated but it's about PDF and somebody mentioned that they are trying to be able to read PDF and for instance me this is one of the big issue I have at university it's like I want to use a accessible reader but in some time I have always PDF and sometimes I have to switch between one reading up to another and even if it's not accessible, I sometimes have to have to read it and I do it. And so yeah, I would be curious to know what are the thoughts on this. And the other question is, I'm just curious about if you managed to get perspective from this flexic reader in your feedback because it's quite different needs in terms of accessibility so It's a good question. I don't know Rick maybe do you have any thoughts on PDF accessibility. We do it because we're committed to accessibility. It's a pain. It's hard. Mainly it's hard to get publishers to mark things upright, because if they don't mark it upright it's worse, trying to do it than anything else. And reading order and all of that becomes an issue. I mean, most of the people on here who know me know me for the last 20 years of being involved in championing EPUB and trying to get people to move over to that and we're excited. You know we look at the vast vast vast majority of the content that we distribute now to our users as EPUB. It's very small portion of it is PDF now, and we love that we love that trend. All right, we're running out of time and we have two questions remaining so I'm going to be really fast. Rhianne, you're next. Thanks. So I'm curious how reading system companies are ensuring that people with lived experience and their expertise are being utilized and ingrained in all aspects of what they do. Who wants to go first. I can, I can say we work together. Yeah, we always, as I said, we have, we always implement and eat our own dog food, we implement our own reading systems, as I've said, and we have testing groups from Daisy and know I get feedback from from blind users and my daughter is dyslexic so she uses. I mean I'm the worst ADD person you've met so I also have my problems really. So, yeah, but we use Daisy and people who communicate with with me through. So you're not playing anyone. No, as soon as we have finances enough to do that we will definitely do it because so it's on our roadmap, most definitely because we need it right so. Great, thank you. Thank you. We have some associates with different disabilities, and then we also contract out annually to make sure that we can bring those people in to make sure that we have the testing needed to close those gaps. Anything outside of testing. Not sure I understand what you mean. So like, you know your human resources your other aspects outside of testing like your development, your marketing. Yeah, we without getting into specifics could probably name half a dozen different people with different accommodations required both in marketing in developers we've got three blind developers different accommodations in different areas. Hard to get into specifics on the public call like this. Oh yeah no I understand. Thank you. All right, and we have one last question and one more minute so Megan go ahead. Okay, I might follow up after to get more of a detailed response but I'm just. So I work at UBC press and just wondering how best can I communicate bugs and issues when it comes to accessibility with ebook developers or either developers. I'm sure we can all post in the channel are emails slash the places that we have on our site so I have Kobo has an accessibility email that we put on our website for anyone to reach out to but we can put that all in the channel because you can reach out to any of us and I'm sure we would all and happily answer your questions or get your issues. Oh, I'll follow up after it's all the more and up thanks for your time. Thank you so much everyone and we'll see you all back in the main room. Thank you to our amazing panelists, you guys did amazing. Thanks Wendy. Thanks everyone. Thank you everyone.