Building a Wagtail-based site and authoring environment with accessibility in mind (Zarina Mustapha)

Speaker 1: So because I'm talking about accessibility, so there's this little thing here. This is Google Slides. I don't know if people notice that there is a caption. So we could try that out and see how it works. So let's see. So my name is um oh hold on. This is So my name is Zarina Mustafa and I am a senior front-end developer at Columbia University. And my department is called the Center for Teaching and Learning. And

Speaker 1: what we do is we serve the community of practitioners of education faculty, instructors, students, and we are a team of 40 people and the software development team is five people and I am one of the five. I'm a front-end developer so my focus is mostly on web-based applications that we build for the faculty clients My focus is on user experience and user interface. And for the past two years I've been working heavily on accessibility. So why accessibility? T -Bode already went over why it's necessary for a tool to be accessible, but there is another bigger implication

Speaker 1: why now we're hearing so much about accessibility. A whole talk can be devoted on accessibility, but it's enough to say that technology is so much part of our lives that we forget about it. Like if I lose my phone today, my fits bit will tell me that my heart rate is now peaking because I'm panicking. So it's all part of it. And as we are becoming more intertwined with technology, all that technology serves become so fundamental um service to our lives and as we have a demographic demographic shift. from baby boomers to becoming like the biggest generation to grow into a certain

Speaker 1: age demographic. And then we had the digital natives coming in to replace that. It is now shifting the economic demo uh the economic outlook also in in in the world or even in the United States. And it became a much more urgent and fundamental issue that it now is going into human rights. So this is why accessibility, you're hearing so much about it everywhere, whether it's software development or in the media. So this is not accessible because the the print is too small, but basically unless you're Mary Poffins, practically perfect in every way. You will benefit from inclusive design and accessibility.

Speaker 1: Anybody who wears glasses will know if you can't find your glasses, you can't see anything on the screen So that's like the minor, minor excessively all the way down to minor impairments, dyslexia, colorblindness. all kinds of like um impairments from not being able to hear different tones all the way up to just not being able to hear So my department, our guiding principle is because we work at Columbia University, education is for everyone. And we have to ensure that learners and educators of all abilities can participate in the education practice. So

Speaker 1: our practice is guided by the Universal Design for Learning, which is a concept that is based on the science of learning. Inclusive design principles, which is governing design of software to physical space, and of course, you know, the standards that T-Bord already talked about, which is we CAG What I focus on primarily is digital accessibility. So anything that we build online or any applications that we build for smartphones. All of our applications and software and websites, they need to be device agnostic. They should work on desktops, tablets, smartphones.

Speaker 1: They need to comply with WCAG and guess what? You need to print because people still do print and you'll be surprised how many sites don't pay attention to print Um when you print it doesn't make sense. So you have all those part, which is just basically user facing But how do we build something that is accessible on the user-facing site when it's content? So Wagtail is a CMS. Wagtail is an accessible tool. But then how do we build the experience to actually encourage accessible thinking and accessible culture? for content um creators. So we could do that through actually having the models

Speaker 1: be more compliant to accessibility and we should build the UI so that accessibility is no longer something that you think about, you just do it as a content provider. So one of the examples is like this is a structured content of a website that I presented last year. The model defines every little component to map out to all of the components on the website. But This is something that we already define. We say we want an image here and this is the what the image should look like. But what happens when the website is just basically the skin, the theme, and just content in the middle, and we have no control over what the person

Speaker 1: puts in there. They can put image, they can put text, they can put tables. without any well-defined model. And this is usually what happens when we build sites with WordPress. You have one blob, put content here, and then hopefully for the best, you know, good things will happen But no, everybody has different experiences in how they put content in. They cut and paste. They grab images from The web, they make their own image, they put it there, they they present graphs as images, not like graph is graphs. So how do you solve these problems when you have so many uh different People with different experience and different style of putting content in.

Speaker 1: So here we have a you know as I said before, so you've got here in this particular site, for example, we have headings We have text, we have images, any purpose, tables, videos, you know, anything, anything at all that you can think of So I'm gonna walk through a particular project that I was working on this year, developing an authoring environment for a project that was on Movable type and now because it doesn't work anymore we're moving it to Wagtail. It is uh for a client in the program of averting maternal death and uh disability

Speaker 1: program at the Mailman Public Health at Columbia. Uh the project is basically uh case study of a fictional country called Lanratam, which is basically maternal spell backwards. And it is like basic, it's a it's a ministry of health. It has lots of information about the situation in um maternity mortality in Land Rotem and the students in the class will have to figure out how do we deal with the situation, what kind of advice do we give to the politicians and leaders, what kind of policies do we build for uh this sort of situation.

Speaker 1: So why do we choose Wagtail instead of WordPress or Drupal? We all know that Wagtail is flexible. It starts from zero. That's great because you can build up according to how the client preferred to move forward in trying to build the content for the site. Now the UI for the CMS can be customized fully and this is where it's very important because it shapes behavior in terms of how you want to put the content in. And then By shaping that behavior, you are shaping the authoring experience. And hopefully, you know, it becomes intuitive as we move along. So I mentioned earlier, so we have heading and text. These are content components that we identified from

Speaker 1: the old website. And then we went with the client, asked if there's any other components that She would like to add. So we have heading and text, images informative, meaning the image has something going on that provides information. Complex. Graphs, complex. Um, charts with organizational charts, it's complex. Decorative is just an image of a building just to break text, so it really doesn't bring any value to the content. And we have tables. uh with headers and columns and whatnot and then we have a special interactive map that we build for them. Um so what I use is basically Wagtail Stream Field.

Speaker 1: Uh who here is not familiar with Streamfield is Everybody's familiar. Great. So I don't have to talk a lot about it. So you got draft tail for heading and text. And then we have images, an image block. We have um table I'll speak to that later table captions, table cells, and then I have a field called screen reader which maps to um What the tag is called long description is not widely supported by browsers. And then we have a JavaScript activity template, which is another issue. So how do we build this thing then? So we know that the accessibility compliance is informed

Speaker 1: by WECAG standards. There's technical issues to it Something that we can build with templates. We could write the templates, short codes, components for video, components for images, components for forms. But then we have like custom that we can build through the models. So do we need a special class name for a particular div or image or do we need to have a special um captioning for a table? And hopefully when we take all the necessary components for something to become accessible. Build it into Wagtail interface with human

Speaker 1: language, human description. So people don't have to really think about oh I need an alt text. Just give them something that is more intuitive. So let's take a look at something, an example that I have here, which is the image component. So you have an image, they want to put it in the content. So we have here just a regular image tag. We all familiar with that. So the class could be something that we come up with like image fluid that we don't want anybody to change Or we could provide an option for people to put in a class name or an ID name and then the source the the content provider will provide.

Speaker 1: So this is from the draft tail um interface when you hit the button there and then that thing comes out has all the formatting whether you want to left the line so that's the uh the custom class and then you have the alt text so this is like out of the box wagtail But what if I want a more complex description or use for that image? So then I want to have say a caption and I want to say have formatting in the caption and I want to have attribution right there with different kind of formatting

Speaker 1: So here we got the same um image. So the proper semantic WCAG -friendly is to have that tag over there for the figure because then you can have fig caption and the screen read reader will identify it properly. This is a figure and the fit caption belongs to the image as opposed to just some random text that comes after the image So you can have attribution there and you can have like a the rich text environment for that particular caption. So this is where when I built the UI, this is where the UI promotes behavior. So you do have the image file and you ask them to put down the image description.

Speaker 1: And you can say, you know, I have a manual that I provide to the client saying that what's the difference between caption block and caption? And what's the attribution? So when they put it in, you know, so you will get back, you know, so there's an image and the screen will reader will read. a photograph of um a clinic building as opposed to the caption which is the maternity clinic is located in the capital city so they're two different things So we build it into um the template and we build it into the UI. And they both sort of like complement each other and hopefully this will model more behavior uh a better behavior in terms of accessibility thinking for content providers

Speaker 1: Another example is table. Tables are particularly difficult because it needs a caption To explain what the table is about, it needs to be tied with a table. So you can't really have a heading because then it reads heading, then whatever. But if you put a caption, then it'll say table caption, whatever that table is And then you need a head, you need a body, and then if you do have headers, you need to tie that to the columns and row, provide the scope for the data And then you probably want to have some kind of aria label, describe pepper throughout. So the way Wagtail is structured right now is a little complicated

Speaker 1: and I have limited knowledge of how those things work. So basically I built this table caption field which is right next to the table and it just translated to into a heading right above it. It's not really great, but that's the best thing I can do For the screen reader text is basically a field that I would give the content provider so they can put things in there that will be hidden visually but will be read by the screen reader. An example would be a very large complex graph. You really don't want very large alt tags because it's not going to show up. It's going to be very

Speaker 1: There is like a limitation in terms of like how much um alt text becomes useful in in an image. So we provide, you know There's a graph showing growth of something something in this particular economic situation. So that is hidden, but the user can actually enter that quite nicely. So as I mentioned before, in terms of templating, I don't quite understand how things work. My wish item would be for the next iteration of Wagtail, there will be better templating to start. I use the word short codes here. If anybody has ever used Hugo, static site, they do have short codes.

Speaker 1: Meaning that It's already there in the template that you can customize later. It comes out of the box and then you can just take it, make it your own. Put things in and then done. It is not tied to the model. I mean it's not inside the models. py or blocks. py. It is part of an HTML that you can customize So that would be great to have if we have something like that. So that the designer or just the front-end developer can actually work on it without much knowledge on Python. So that's it. It's a short talk today. To be continued. That's a

Speaker 1: yeah. Any questions

Speaker 2: Did it work?

Speaker 1: Did it work? What do you mean?

Speaker 2: Have you found that the clients are actually producing better, more accessible content?

Speaker 1: Um So far because the client's content are already in there, the client is just editing. What we want to do is probably model uh use it as a model for something else that's very You know, that requires a CMS. Um the one that I showed earlier, which is has a structured content, that's not quite what It's not quite free form, it's structured, so you have to enter text here, blah blah blah. We don't know. My group don't usually get projects. that have a you know that have a need for CMS. We do a lot of Django apps.

Speaker 1: So we'll we'll find out for if we get another project, something similar to that No , good. Oh hi.

Speaker 3: I don't quite understand what you meant by the short codes.

Speaker 1: Okay, short codes are um so Hugo is a static side generator. And uh they have the uh a call for a particular template. So figure, for example, figure, and then you put source equals whatever And then it's inside their um um in inside the MD files that you when you put the content in. But that's that's how they call the shortcode. But the short code is actually a template of a component. So a component like um one second. This is

Speaker 1: a component, a figure, an image. So they give you variables. for you to fill in. So for example, you have a very I mean you already have it technically in Wagtail for source, for attribution. But The code wrapper is very simple, it's just image. But to have something like this, so I don't have to go hunting for the template and then make my own template. But instead have it separated. Okay, here's the figure template. There's the table template and here's a video template. So simple components like that If you don't need it, it sits there. If you need it, you could

Speaker 1: port over and customize and put things, a wrapper around it, etc. etc.

Speaker 4: Like little partial templates that you can also pass parameters to.

Speaker 1: Yeah. But the key point here is that um Developers can go in and do all the things in models and all other Python code, but for people who are straddling between the front end and the back end This is as you know the easiest to handle and um uh and there are a lot of like um uh uh we cat guides that we probably need to follow and we probably need to add and you know like aria tags would be great if we have it here if we don't have it then what are we gonna do kind of thing Yes, sir.

Speaker 3: In one of your early slides, you mentioned that sometimes people use uh or fs as images.

Speaker 1: Yes.

Speaker 3: So there's no other information. Yes. How would you handle a situation

Speaker 1: Graphs are tricky. Graphs, there are many, there are a few um groups and companies that focus on graphs as graphs. as opposed to a screenshot of a graph. There are many different non-ideal solutions out there. Some people recommend that you take all the graphs and turn it into a table and then have the screen reader read the table, which is pretty cumbersome because then when you change the graph then you have to change the table and then all kinds of stuff going on But HiCharts is one of the companies that work with academic journals to actually make graphs that are interactive and accessible.

Speaker 1: But um that's um I find it it's a great start, but there are so many different kinds of graphs and charts that we still have to figure out. Um what to do with data because a graph is data storytelling. And you can tell the story from different perspectives just looking at things. And that's like one of the other Interesting thing about trying to decipher graphs, like when you see things, you see patterns, but when you hear things, what how do you hear patterns? So there's a talk in New York by this other person who's talking about how they're developing a whole environment of accessibility just for graphs.

Speaker 1: W to be continued again. That's it. That's it. Okay, good.

Speaker 4: Thanks, Lorena.