I installed CloudTube (and Second) today to replace a former Invidious instance. A heartfelt thank you for creating this! It has been a bliss, both the installation and the initial few hours. Me and a friend (whom has more experience with accessibility) went over CloudTube and gave the default installation a small audit. I'd like to share the majority of the findings and the fixes:
The language of the HTML document is not defined, both in /pug/includes/layout.pug and /pug/includes/head.pug. This prevents screen readers of reading the document in the correct language, proper pronounciation and appropriate accent.
Fix : add a new line under doctype html with:
html(lang="en")
The search bar in nav and on the home page don't have a label (and a placeholder isn't a viable alternative). A label creates a programmatic association with the field, which is important for assistive technology.
Fix: There are a few possible fixes. Creata a label with the label element or add an aria-label to the input elements. For example on the home page:
input(type="text" name="q" placeholder="I'd like to watch..." aria-label="I'd like to watch..." autocomplete="off").search.base-border-look
Read more: WebAIM: creating accessible forms, MDN web docs: label
On the video page, there is an aside element (the Related videos) within a main element. This is incorrect mark up, since an aside can't be a child element of main.
Fix: place the aside outside main or change it to a div (a section is not allowed here either, since it can't be used as a general container element) in /pug/video.pug:
section.related-videos
Read more: MDN web docs: the aside element, MDN web docs: the main element, MDN Web docs: the section element
an H1 is missing on the channel page. Visually, the name of the channel is styled as a heading. The rule of thumb is that if it looks like a heading and behaves like a heading, it should really be a heading. This also helps with indicating structure and hierarchy for user agents and assistive technology.
tip: use a contrast tool as WebAiM contrast checker to check the contrast value of old colour combinations and new combinations.
The contrast for placeholder in the search bar in the nav and on the home page isn't sufficient enough. For text, a contrast value of 4.51:1 is advised, to prevent problems with low vision and colour blindness.
Fix: in /sass/includes/base.sass:
select, button
font-family: inherit
font-size: 16px
min-width: 0px
input
font-family: inherit
font-size: 16px
min-width: 0px
&::-webkit-input-placeholder
color: white
&:-moz-placeholder
color: #c4c4c4
&::-moz-placeholder
color: #c4c4c4
&:-ms-input-placeholder
color: #c4c4c4
Link color doesn't have sufficient contrast. For text, a contrast value of 4.51:1 is advised, to prevent problems with low vision and colour blindness.
Fix: in /sass/includes/colors.sass:
$link: #8AC2F9
On the settings-page, the arrows on both dropdrown elements have insufficient contrast which makes the arrows hard to see for people with low vision.
Fix: the arrows are an image, change the colour of the image to colour closer to white than to grey.
Ensure form elements (dropdown b0xes, input fields,...) have a more apparant border. The colour of the current border has insufficient contrast, which makes it hard to see for people with low vision how big the fields are and that there in fact fields present for user input.
Thank you very much for going through this, and thank you for the kindness in the way you have written this! I care a lot about accessibility and I want to make things as nice as they can be for everyone.
Before I make any changes to the code, I do have a couple of questions about your report.
The language of the HTML document is not defined
Should it be?
I believe the lang attribute applies to the whole page. The page may contain video titles and descriptions that are written in another language. As an example, https://tube.cadence.moe/watch?v=dhetke_sweQ is not an English video, and its title and description should not be treated by screen readers as if they are English text.
Create a label with the label element or add an aria-label to the input elements.
Okay, sounds good! Do you think it would be more appropriate for the placeholder to read "I'd like to watch" or more simply "Search"? I feel as though "Search" may create a better experience for people using screen readers since it takes a shorter time to say. Please let me know which is better.
Thanks for all your suggestions! Everything else that I didn't comment on sounds good, and I'll make those changes soon in the future.
Thank you for your kind reply :) Really appreciated. And I think you ask some good questions.
I believe the lang attribute applies to the whole page. The page may contain video titles and descriptions that are written in another language.
You are correct, the language definition for the HTML document describes the entire page. Since CloudTube has an English interface,
html(lang="en")makes sense here.That the titles and descriptions of videos are in another language is not THAT big of an issue (though it is still an accesssibility violation), since screen reader users are (sadly) used to that. Is the information on the video language included 'upstream'? Eg, would it be possible to grab the language from the YT response and to define the language of the video title field and description field seperately as well?
Do you think it would be more appropriate for the placeholder to read "I'd like to watch" or more simply "Search"?
To make things more clear: a placeholder is not the same as a label. A
<label>element is needed here, and it needs to be visual as well (we understand accessibility a bit better now).Regarding the content of the label: "Search a video" would be best, as it would be short and sweet. Just "search" would be more appropriate for a submit button next to the input field.
Sadly, YouTube does not appear to give any data regarding the language of a video or its metadata. (I checked the HTML tree and the yt-dlp JSON output, and didn't find anything.)
I did notice it does have a lang attribute on its website, however, this reflects the currently selected language of the interface, rather than the language of the content within.
Even if there was data for the current video it would still be mismatched for other data like the titles of recommended videos.
I won't include a lang attribute in my pages so that the screen reader software can decide whatever is best. There is more text in title, description, and recommendations, than there is in the CloudTube user interface. And who knows, maybe the reader software would be smart enough to pick up that some elements are using a different language than other elements.
Once again, thanks for your review.
Cadence Ember referenced this ticket in commit 5a5901d.
Cadence Ember referenced this ticket in commit e97d1b9.
Cadence Ember referenced this ticket in commit bec802f.
Cadence Ember referenced this ticket in commit 4bd832e.
Cadence Ember referenced this ticket in commit 893c22a.
I believe I have addressed all of the issues that you raised.