This recording, from the April 7, 2020 Community Call, contains a conversation about the accessibility features of the new theme being designed for inclusion in VuFind release 7.0.

Video is available as an mp4 download or through YouTube.

This is an edited version of an automated transcript. In the near-future, I hope to edit this conversation to attribute to each speaker. Apologies for any errors.

Good. I want to give an update and get some feedback about the new progressive theme is what I've been calling it. The new theme that's going to be coming out with 7 and kind of highlight where my priorities are and since it's fairly early in the process of turning my static design into actual VuFind code the way that I build it is still very malleable so I was hoping to get some feedback so everyone here on the call and also everyone who's seeing this recording I would love to see hear your feedback on a couple different things and the best way and the most flexible way to go about handling it.

So to start off I haven't I'm going to share what I have done. Now I haven't managed to touch every part of VuFind yet but I'm slowly working on it but I wanted to show you the overall style that I'm going for and highlight a few of the details of what my priorities and my focus are on.

So obviously progressive will be a rewrite of the entire theme to include maximum accessibility design and also include the new features such as slots that we came up with to make VuFind even more accessible and even more not only for like for strict accessibility reasons but also for developers who want to do customizations and things like that.

So the overall design is going to be much more easy to customize especially through CSS and I wanted to show some of the like some of the features and just a few of the pages of what it looks like to kind of highlight some of the ideas that I've been working on to try to get this to work as correctly as possible.

So first of all the overall style is I'm trying to keep it to just a couple colors and I'm testing those colors extensively against CSS checkers, accessibility contrast checkers to make sure that I can get as close to AAA compliant as possible. If the new theme comes out of the box AAA compliant I will be completely thrilled. Hopefully we can get that far and some of the ways I'm going to do that are by very carefully styling and allowing for the control the like keyboard control of a bunch of different elements.

So, I'm going to switch over to a different demo to show. This is just the design demo, so it's slightly different, but you see, as I focus and tab through the page, I'm trying to do a lot of keyboard accessibility. Is that all these menus? Oh, that's still broken. All the way that the focus jumps around the page is from important feature to important feature. For example, all the links are obvious things. These are description lists, which is a very accessible way of going down and making it very easy to navigate through the details and see what you want to. These have full keyboard control, so I'm using the arrow keys right now, using the ARIA guidelines to open and collapse all of these elements, and also when you tab through, it tabs from facet to facet, not through every single item inside the list. So even if this was open, as I tap through, it would just jump down to the next facet. So things like that make interfaces extremely accessible, and I want to put as much of that in here as I can. That's being done in two ways: one is with the keyboard functionality, another is with what I'm kind of calling “false menus.” So, for example, if I reduce my screen size a little bit, here let me do that with a console. The header would start to collapse. We're using CSS grid now into a hamburger menu. I know it's a corny joke, but it's made me laugh every single time it happened. So, this menu, to visual users, is a button that you click and it opens and closes, and it's very collapsible and visually closed. But a screen reader doesn't necessarily care about this, and, I guess, more importantly, a visually impaired user doesn't really necessarily care that it opens and closes. So, to a screen reader, it just looks still like this, even when it's collapsed. It's just two links next to each other, two buttons that you can choose where. So, the button is not ARIA hidden, and the fact that the menu is open and closed is not something that's included in the ARIA attributes because it doesn't really matter so much to a visual user. This is something I'm calling a “visual only menu.” This is one of the things I'm hoping can make VuFind a lot more accessible and a lot simpler.

This is another one here, “remove from list.” This toggles and opens and closes on a visual level. Before a screen reader user, this “remove from list” button is hidden, and so they would just read “saved in these lists,” “removed from this list,” “removed from that list.” So, they get the actionable content there without having to hear any of the extra open-close button madness that's part of that. I would love feedback both on that overall approach to things, the keyboard navigation, and if there are good sources outside of the ARIA documentation for that, and this “visual only menu.” But also, how we implement this in the most developer-forward way.

So, right now, we're thinking about doing PHP helpers where, if you want to make a menu like this, you can use a PHP view helper. And so, you would say, you know, you'd give the content of the button and a list of items with hrefs or something like that, and it would build this menu for you in PHP to make sure that it hooks up properly and has all of the needed attributes to work correctly. The same thing for JavaScript menus, such keyboard menus. Such as this, the other option that ARIA talked about. So, just shame the ARIA's not here. We talked about it if not the last, you find some of the one before that is actually building web components. Now, this would probably be much, it's more building custom HTML elements is something that is definitely an approach that we can take, but I think it'd be harder to customize. But it's definitely a more modern approach for what that's worth.

So, I guess pause here for any feedback so far. But right now, it's in order to create these more advanced, more accessible elements, we're gonna lean on PHP helpers to make sure that all of the things are in the right place without stressing the developer too much for all the small details about different things. I would also say the advantage to the PHP helper approach is that if in the future we do want to reimplement these as web components, we just change how the PHP helper operates, and we could seamlessly plug in a web component in place of more complex PHP-generated code as a transitional step.

Take it by your stun silence that this is that we're heading in the right direction. Yes, yes, I fully agree. We've been trying to do something rather similar because by September we have to have our websites accessible, and so keyboard navigation is key. It seems to work very well what you've demonstrated, the facet collapsing and opening, and the jumping from facetating to facet heading is really nice. Really like that as well as the hamburger menu seems to be perfectly sensible. And yes, this is absolutely the right direction, I think. Great, are there any resources that you're using to get the keyboard navigate? Is there a particular library that you recommend? Because right now, the best I found is the ARIA guidelines come with example JavaScript. I'm kind of transforming that into just the useful bits that we need and using it as a guideline. I could, I wasn't able to find a comprehensive library that handled that, turned our like properly ARIA labeled elements into the keyboard navigation that they suggest. It's something that we would definitely open source and share as a separate module if we can't find it. But finding such a thing would probably, finding and contributing to such a project would probably be more, you know, a better use of time than building something from scratch. And then of course, sharing that out. I haven't found a library yet. We do the same thing. We just go bit by bit and using the examples just as you do. That was, I think, in Boots, in an earlier version of Bootstrap. I think there was a library that transformed such things as carousels into ARIA accessible elements. I can, I can look it up. I have it somewhere. And they had some general items that they introduced to two non-accessible websites, Bootstrap websites. I think the project has been abandoned with Bootstrap 4, but apart from that, we have no library. Go bit by bit. We have our website and catalog tested, and we just had an accessibility course with our accessibility cracks here from the library for the, we call the library for the blind. But they don't know what the term is. Visually impaired, yeah, could be the right term. And they are the accessibility cracks here. And so they have to say, I had the same recommendation.

Just at the moment, go through it bit by bit and tested, tested, tested. So they also suggested to do a full screen reader test, just as a visually impaired person would see the page, read the page, and have it read out to you. And you come across countless tiny little things or we do, we've missed. So it's a hard way, but I think it's probably the only way at the moment. Yeah, I've been using a screen reader installed. I think it's the NVDA screen reader. I've been trying, I've been using. I found and I'm also trying to wrestle the Windows 10 built-in screen reader to kind of help. I do also have an iPhone, which has a good easy to start voiceover. Although I, I've not, I'm not used to the experience, so actually controlling the screen reader is something that I'm still learning, but I'm, I'm going to make important passes over that. I'm also in search of a tool that can take a page like this and turn it into what the screen reader would read if it just read from top to bottom. That's also something that I haven't quite found yet, but there's, there's all kinds of little small screen reader-only bits that are hidden throughout this page. Like, there's a small title label here that would, to match this one, and there's little bits here and there. So, these little badges are aria-hidden, but it reads them right after the title. So, it reads the title and then says “book available,” which just is a better way to go about it. So, I'm trying hard not to create two completely different experiences but try to make the screen reader use as least aggravating as possible. Do you know the Wave plugin for Firefox? I'm not sure whether it's available for Chrome. It's called Wave, like WA OH, yeah, yeah, I see. Okay, yes, I use Wave, and I also use axe, catches a few different other ones. Then also through Villanova, we have, I'm not sure if we can hook up this way, but we have access to Site Improve, which is another one, broken links and spell-checking is its bread and butter.

But we'll have, we have a bunch of different tools available, and I'm trying to use as many as I can. Hopefully, if I as I build it slowly and keep checking along the way, it won't be that we have to solve a bunch of problems at the end. It just wants to polish a few things and make it perfect again. It's the idea. So, that's exactly the same things they were suggesting. Site Improve, Wave, use what you.

I also have a few questions. I also think that it's absolutely going into the right direction, so I'm pretty happy to see what you've already achieved and where you're going further on. I just wanted to know if there is kind of a full list of all the things that you try to achieve now because we also started optimizing some of our websites for accessibility, not pretty much, so our VuFind pages, but some of our other sites. And pretty much our goal is to have everything implemented which is set to be accessible due to the BITV standard.

Now, I do not know if there is any standard or anything that you try to follow, but this one is like, yeah, it's like by law in I'm not sure if it's in Europe or in Germany for the official pages of like official corporations, libraries, and so on. And that was like the list that we tried to implement. Yeah, and it also has lots, lots of regulations, like also for color contrasts and for image tags that need to have always alt attributes and all kinds of stuff. So I just wanted to know which standard you are following, and maybe I can have a look and just see if there's a difference between the BITV and the one that you're trying to implement right now.

The standard that we're applying for here, so we are very lucky to receive training through Villanova from the WebAIM team, which is very, very, they really, really know their stuff. They're like the foremost experts. We're very lucky, and they use the WCAG or the WCAG, I think they called it for fun standards, the Web Content Accessibility Guidelines. They have a hand in not only tweaking these, but also helping write and make recommendations for these.

So when I say AA and AAA compliant, that's because of these particular guides for each possible for each individual thing. Maybe not in this version, but in an upcoming version, they describe something you can't seem to find a good example, but they'll describe a problem, like a common problem, and then they'll say, “In order to meet AA standard, you must do this part of it. In order to meet AAA, you must do this part of it.” So, for example, there's the first one I'm thinking of for live streaming videos. If you're live streaming a talk or something like that, having live captions is what you would need for AA compliance. To meet AAA, you would then also need to make the transcript available in plain text afterward or have a live sign language interpreter available. The AA standards are that we would hope that you would do this, and AAA is like if you really want to go full out to try to make it as accessible as possible. Here's what you can do. Usually, when we're talking about the guidelines that are going to affect VuFind, we're talking about the contrast guidelines, the header and outline guidelines, and the keyboard accessibility ones. But I can make a full list of goals available. I'm not quite at the point where I'm ready to pull request with the changes that I've made, but when I do, that might be an important part of the document to include. It's like, “This is the progressive theme. These are the goals the progressive theme is trying to meet. This is how we're going about it.” Having all of that on the pull request and then maybe also on the wiki would be, I think, an important part of it. So that way, all contributions can kind of point towards the same goals. In Germany, the rule is, as Mario mentioned, the BITV, but that is, or equals, the WCAG 2.1 AA, unless you are a state institution. If you're a state institution, you have to meet AAA standards. So basically, if you bring VuFind up to AA standards, that meets the BITV standards of Germany. That's very good to know.

Thank you. Excellent. If there are no more questions at this point, I want to talk just briefly about how I'm building it at this point, the actual underlying code.

So right now, I am building all the styles in Sass and SCSS. I chose Sass over Less because of the overall community usage on the global level, not just the VuFind community. But looking at things like the State of JS and the State of CSS, Sass seems to be one that's more widely used overall. We also managed to recently implement a PHP compiler for Sass. So now, Less and Sass are equal players on the field, as far as it goes. I'm still open to using Less or Sass, or adding features or something like PostCSS, which would give us a lot more control. But I think right now, Sass is a good place to start and definitely gives us everything we need to go forward.

The other more low-level question that I'm still trying to figure out is, since the previous VuFind themes were built, especially the Bootstrap theme, JavaScript has added a bunch of new features that do a lot of the things that we were doing in the Bootstrap theme. For example, in the Bootstrap theme, there's a core VuFind object, and all the other bits, like the lightbox and the record controller and things like that, are added on to that module style. You can give it a name and you can pass in a function, and then it calls `init` for you and it loads at the proper time and things like that. It was pretty close to what has actually come around as actual JavaScript modules.

Now, I like JavaScript modules. I think they're a good way for organizing code, and I think that turning the current VuFind's working code into JavaScript modules would be a great way to break it apart and would allow for any developers who want to use a tool like webpack to go ahead and optimize their site fairly easily without a lot of configurations. The problem is, I need to do more research on JavaScript modules because I don't want it to raise the bar of how difficult it is to get into customizing VuFind's JavaScript. Right now, in most browsers, you can only use JavaScript modules if every single bit of JavaScript is a module, which might make small interface tweaks here and there and inline JavaScript more difficult to handle if they can't access the module.

So, I'm still working on the best ways to load those modules and incorporate those modules, and there's a chance that it may not be too different from what we currently have working, which is straightforward and understandable. It just won't harness a lot of the modern browser features, like dynamic module loading if we wanted to get into that or things like that.

Right now, I'm considering building everything as a JS module, and what I might do just for the development side of it is I might go ahead and build it as JS modules in as modern JavaScript as I can, and then have it compiled using something like gulp into a target language. So when we make the decision later down the road of, “Okay, we want to hit this level of JavaScript or use these features of JavaScript,” I can then switch over to working directly with the compiled code. That way, I can continue development without having to wait for this decision. So, if we decide going forward we want to use ES 2015 or the latest version of JavaScript that comes out in the next two months, that decision won't slow down or completely halt development because I'll be working in a codebase that I'm comfortable with, and then compiling it into what eventually our target will be. And then we start working from the compiled code, which would be all I would be committing from there.

As far as the overall JavaScript approach, I'm definitely open to feedback. We're early enough that it's very malleable, and using things like data attributes and also custom attributes such as aria-menu, as opposed to aria-equals-menu or role-equals-menu, would allow the JavaScript to get its hooks on the right element and turn it into fully keyboard accessible elements with all the right attributes and things like that. Trying to find the right balance between flexibility, conciseness, and accuracy is a fun challenge. It's a good place to be, but it also explains why in the demo right now, I only have the home page, the search page, and half a record view. I'm trying to build everything, trying to get the foundation at this point so that a month from now, we can hit the ground running and quickly develop everything.

Are there any strong feelings about actual JavaScript construction approaches? I mean, my biggest thought is it would probably pay to pick a strategy that allows you to take as much existing code as possible as a starting point and then refactor and change from there. Given that we have a lot of JavaScript and some of it deals with specialized features that aren't on by default, that require configuration defined, and like anything that will minimize the amount of stuff that gets broken and has to be rediscovered and fixed, the better.

And of course, going with that, the more stuff that we can test, if we're not already testing it, the better. I think we should think about a testing strategy for all of this as we go forward. Do we need to rewrite all of our existing tests, or is it possible to make the tests apply to multiple themes, maybe with some conditionals or how should we approach that? Because the biggest risk from my perspective of having a new theme is breaking stuff because we have so many options and so many settings and so much code. It's really easy for things to get lost in the shuffle, and I'd like to minimize that as much as possible. Hmm, I fully understand that. At the same time, I think it's impossible not to run into issues because, as Chris just mentioned, JavaScript accessibility guidelines mentioned one key feature, which seems to be modals. But if you use modals, they tend to be unusable when the focus jumps out of the modal at the end. So basically, I have to keep the focus inside the modal as long as the modals are open or the lightbox is open, which can be done with JavaScript. The probably the more difficult point is that once you close the modal, the focus has to be at the point where you triggered the element that made you jump into the modal. So we might actually need more JavaScript because of the accessibility things, and I guess it's just gonna get more complicated. The additional challenge of using the existing JavaScript is that one of the goals is to make VuFind more framework-agnostic, and a lot of the work, the modals are a great example, was using the Bootstrap lightboxes and modals to make a lot of that happen.

So it's not a matter of building everything from scratch. Actually, I've really liked a particular library for modals, which I picked because it was very simple and had a lot of accessible features. Let me go and actually test it to see if it meets that one particular criteria. So, let me see if I can quick tabs to pop up in a modal. Then the tabbing is contained inside the modal, and when I close it, yep, the focus went back onto the button.

So it's not a matter of doing everything customized ourselves. What I'm looking for is the right library. It's just a matter of using Micro Modal, which is a very small ARIA-compliant one feature that saves us a lot of headaches. Finding the right components will immediately make things better. So as far as the keyboard goes, we've passed the responsibility of the keyboard control of the modal to this library that I found. And finding the right libraries, especially for things that require advanced ARIA keyboard control, might be something that is worth going forward.

Yeah, and also to clarify what I said, I certainly have no particular attachment to any existing JavaScript code or templates. I just am attached to the underlying functionality. And I've found that when updating things and changing things, it's helpful to be able to start with the existing code and rewrite and replace it. So that if I delete everything that I've rewritten and replaced as I go, then if there's some obscure feature, I run across the code for it and then have to figure out what is this for and how do I reimplement it in the new environment. As opposed to if I start from just a ground-up build and try to rewrite the functionality from my memory of how it works without consulting the existing previous code, then I am absolutely certain to miss things, maybe even really important things.

So I'm just advocating coming up with a strategy that really takes into account at a deep level what we've already got to be sure that it all makes its way over. Or if we do have to cut things, and it's certainly possible, there are some things we have that are nearly impossible to make more accessible, we have a community conversation about whether we still need those things at all.

And I also don't expect that we'll do this perfectly and things will get missed. It always happens. You know, frequently when somebody reports a bug to me, I discover that it's some obscure feature that's been broken for three years and nobody noticed. So it just happens. But like I say, I just want to pick a strategy that minimizes those kinds of problems. Nothing will eliminate them.

Yeah, one of the reasons why it's going slow, more slowly, is that I'm trying to make sure that all the features, all the different configuration options are respected. It might be a matter of using the config files as a starting point. This is not necessarily the code, because some of the especially the sidebar is famously complex and famously hard to parse. Whereas the way I'm sharing my screen is gonna make it difficult to show, but the way that I've rewritten this part of the record list template is much easier to figure out and parse and think along the lines. And a lot of that is the changing of the actual HTML that it's producing. The part of that is also we're just realizing how it can, like, seeing the overall picture without the years of implementing a feature and then adding this and then adding this and fixing this. I think overall, it's going to be much more readable.

Also, figuring out guidelines for making everything match across the templates is something I'm going to use PSR 2 for now. But going forward, trying to figure out the right… you know, there's a lot of room for opinion. So adding just droplets of opinion here and there is going to be the strategy over the next couple of calls. I also think documenting changes as we go would be very helpful, so that we can have some kind of an upgrade guide at the end of this, particularly if we make choices like changing the way things are broken down into parts so that, you know, the same template files no longer do the same things, which certainly seems like a possibility in the sidebar, which right now is chunked out into a bunch of sort of nested pieces, and maybe that will change. But just so we can say, you know, if you have this dot phtml in your custom theme, you're going to need to reimplement that by instead overriding this template and using these view helpers to fill this slot or, you know, whatever.

But it's easier to document those things as you go than to figure them all out after the fact, or at least usually that's the case. I'll start up my dev logs again and get things and make sure that things are added correctly. Yeah, I think as far as the scope of this call goes and as far as the work that I have completed and then what I've decided to go forward, I think that's reached the end of what I wanted to discuss. Obviously, this recording is going to go up, and obviously, this will be a months, if not year-long process getting everything working correctly between 7 and 7 to 1. So there's still plenty of time and room for feedback, and I'm always open to it. There's an accessibility channel on the VuFind Slack where we can talk specifically about accessibility issues and concerns and techniques, and also, the VuFind Slack is a good way to get a hold of us, and the mailing list, so there's lots of ways to give feedback. I'm going to try to get the pull requests for this up over the next two weeks or so so that there's a good starting point, so we can all see the code and see the approach, and I think that's going to be the main hub of the conversation about the theme. So that's going to get wild, and I'm looking forward to it. Sounds great. Thank you, Chris, for taking the time to present this, definitely. Thank you, everyone, for your excellent feedback and your attentive expectations. The pressure is good. It's going to mean it's a great thing at the end, so I'm trying to focus the pressure in nice ways. Let's keep this going.