Warning: This page has not been updated in over over a year and may be outdated or deprecated.
videos:theme_accessibility
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
videos:theme_accessibility [2020/04/08 17:41] – created demiankatz | videos:theme_accessibility [2023/05/09 18:10] (current) – [Transcript] crhallberg | ||
---|---|---|---|
Line 7: | Line 7: | ||
===== Transcript ===== | ===== Transcript ===== | ||
- | // Coming soon... // | + | // This is an edited version of an automated transcript. In the near-future, |
+ | |||
+ | 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' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | This is another one here, " | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | Now, I like JavaScript modules. I think they' | ||
+ | |||
+ | So, I'm still working on the best ways to load those modules and incorporate those modules, and there' | ||
+ | |||
+ | 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," | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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' | ||
---- struct data ---- | ---- struct data ---- | ||
+ | properties.Page Owner : | ||
---- | ---- | ||
videos/theme_accessibility.1586367678.txt.gz · Last modified: 2020/04/08 17:41 by demiankatz