Video Discussion: Theme Accessibility
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.
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, 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.
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.
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.
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.
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.