Add alt text on navigation and header items

[shanaqui]

Much of the text on Habitica's website either has no alt text or is not allowing screen readers to read the alt text. This is a serious accessibility issue as it means that anything that is represented solely by a graphic is essentially invisible to blind users of the site.

In some cases there is no alt text, but there is a tooltip. However, the screenreader will not read out the text unless you manage to get your cursor over the tooltip -- for which you have to know it's there.

The following screenshots illustrate just some of the areas I found on the site that are lacking alt text. Red boxes indicate areas "invisible" to the screenreader. Tested using NVDA, a free screenreader available online here.

We should probably discuss what we want the alt text to read and what is most helpful/appropriate in various cases, if this is not simply a display issue. There is some advice on how to form useful alt text here.

[Feywood]

At a quick glance, I'm not seeing any alt text tags which is what I believe most screen readers would grab. The bronze_small is in title tags, but I'm not seeing those either in eg the gem or gold icons in the top toolbar.

[shanaqui]

Me and @Feywood will take this on together. Her to do the coding, me to do the wording. But @Tressley, since you're the designer I assume you know more about accessible design than we do: do you have any guidelines for how you'd like to see us phrase the alt text? Anything which we should consider doing as a priority? (@Feywood's going to add a couple more questions relating to implementation, but I'm making her type it up.)

[Feywood]

As far as design goes: it's simple enough to add some alt or title tags to images on the default website, but that would not, I think, fix the issue of NVDA reading text that is under modals. I think there, it's more of a design issue and perhaps use of ARIA tags? I don't know, I only did a quick glance at accessibility but defining a role for modals seems to be the common solution

[Tressley]

Hey @shanaqui / @Feywood -- Thank you for bringing this up! I feel I may be best for ALT tags, but we may want to loop in our devs @TheHollidayInn / @paglias to handle ARIA tags.

Most of the ALT tags should be pretty straightforward. Gems should be "Gems Owned", etc. Perhaps there is a better way for the crew of us to handle this? Would section by section work?

[shanaqui]

Depends how we're going to define a section? I wonder if the best thing to do would be to start by just giving everything alt text, and see where it doesn't work... that way we try the simplest solution first. (I'm also working on finding another free screenreader to test with, which may show that the modals issue is one unique to NVDA.)

[Tressley]

I define section as a "category" of the site. Maybe we tackle Tasks first (this will touch Group Plans/Challenges) and defining the icons. We could include navigation and header in this "category." We continue from there.

[shanaqui]

Sounds good! I'm happy to follow your lead if you want to organise what people do when, which might be easiest.

[paglias]

I would prefer if this was tackled by sections instead of a single big pr. My only concern is not to add to many new strings so where possible we should re-use existing ones

[shanaqui]

@paglias I'm not sure what you mean by new strings, so forgive me if I'm being obtuse, but do we have existing strings that would work as good alt text? What we already have is there to supplement the images for sighted users. Alt text needs to replace the images in function...

[paglias]

Sorry, I'm talking about strings stored on website/common/locales/en.

We already send about 600kbs worth of strings over the network every time Habitica is loaded so I'd prefer if we could reuse as many strings as possible instead of adding new ones which would mean more data to send, longer loading times for the website and degraded performances for users.

But I'll give a look once a PR is made

[shanaqui]

Okay, I just don't understand then. Hence @Feywood doing the coding bit, heh.

[Feywood]

@paglias I think it's feasible to re-use a lot of the strings if load is something you're concerned about. There are a lot of strings already existing. However, I think this would complicate the coding (at least from my perspective). @Alys suggested elsewhere that it should be simple enough to add everywhere, but with the json, unless I'm quite mistaken, we'd need to add quite a bit of js to tag and populate the images with the necessary text. Again, I'm not too experienced in this and don't know the codebase that well yet, so maybe this js already exists to some degree and we're simply appending a little. However, wouldn't it also be more involved since every potential page would draw from many different jsons or is that irrelevant?

[Alys]

Ideally, all the alt text would be translatable so that it works equally well for vision-impaired users in other languages. That means that the locales json files would need to be used to store all the alt strings and they'd be added to the images using the $t('stringName') function.

We can certainly reuse some strings (e.g., simple ones like gold could be added as alt text to the gold coin wherever there isn't already text that a screenreader has access to) but we will need a lot of new strings. I think we just need to accept this as the price of making Habitica accessible.

[Dangeranger]

Does the Habitica app load only the locales for the given UI element and selected language of the user?

It appears that the locales are segregated by the UI element that they are related to, so perhaps that load optimization is already happening.

If not I wonder if it would be possible to request the locales for the UI element on the page asynchronously, and filtered to the element and language in question to reduce the size of the API response and the blocking time.

Example:

If the user is interacting with a quests UI element, and has english selected as their default language, only load the locales from the file locales/en/quests.json

[paglias]

No, all the locales for a given language are loaded together. The strings are organized by purpose but it doesn't mean that they're only used in a certain parts of the website

For example quests strings could be used in the market, for pinned items in the tasks page, in the party page, etc..

Loading them asynchronously isn't really possible without waiting for the page to render and then decide which strings are necessary and that would be terrible from an UX perspective.

What we can do is

1. Separate strings used in static pages and in the app and load them separately
2. Precompile templates with the necessary strings (unfortunately that isn't super easy as many strings are decided at runtime by the JS on the page)

@Alys I'm trying to balance two needs here: Habitica is already very slow because we load a ton of stuff and that will only grow as more content is added and I consider this an accessibility issue as well since not everyone has high speed connections or live in part of the world, like Oceania, etc that being very far from our servers already incur in very slow loading times. More strings also create performance problems on low end devices, especially mobile phones.

I'm not downplaying the importance of alt texts for accessibility at all and I don't want to think too much about it before any code change is ready but in case this requires adding hundreds of new strings I'd really like to also focus on issues like removing unused strings, moving some API errors that are only meant for developers to English only etc, etc

[Alys]

I've increased the priority on the two issues referred to above (removing unused strings and developer-only strings).

@paglias Just to check something, are all locales files for ALL languages loaded for each user, or just the language that the user is using plus the en language?

[paglias]

Just the language for the user

[beffymaroo]

~@paglias Do we have this covered or should it get a Help Wanted label?~

Got an update from @shanaqui indicating they and @ehlyah will be working on it. :)

[beffymaroo]

@shanaqui Are you and/or Ehlyah working on/planning to work on this soon? If not that's OK, I'll just change the label to "Help Wanted". Let me know when you have a moment!

[Feywood]

@beffymaroo We've figured out how to approach the issue and how the svg elements can be tagged. However, since we're going to be moving and @shanaqui is still dissertationing, we'd welcome the help for sure.

[ianoxley]

I can help out with this if needed?

[veeeeeee]

This is a good first issue for contributors particularly for the header elements. For anything below the header, please hold off as staff would like to make sure the taxonomy is handled logically and consistently across the board.

[projectormato]

Hello! I am interested in working on this issue.

I’m not familiar with Habitica, can you give me some advice on which image needs an alt? (Or can you tell me how to find out?)

I’m not good at English, so I’m using Google Translate (or getting help from friends).

[paglias]

@projectormato basically every img element (you can search for <img in the website/client/src folder) should have an alt attribute

[paglias]

SVG elements as well should have alt texts as explained here https://webdesign.tutsplus.com/tutorials/accessible-svg-methods-for-adding-alternative-content--cms-32205#:~:text=The%20element%20for%20an,have%20multiple%20title%20elements%20embedded. but it's more complex so @projectormato I'd first handle the images and later, in a separate PR, the SVGs icons

[projectormato]

@paglias Thanks, I’ll create a PR by the end of the week.