[go: up one dir, main page]

Page MenuHomePhabricator

Blanking alt text in images in VE doesn't remove |alt
Open, Needs TriagePublic

Description

An editor and I were discussing alt texts because of this edit he made using VE. In the edit, he described that all he was able to do was blank the alt text in the VE image editing form.

Because of that, that left the images with blank alt texts, which leads to the undesirable situation that these would be treated as decorative images. That means they were not accessible.

Obviously the preferred end solution would be to leave an appropriate alt text, but he didn't know what that was in context, and I suspect many editors do not either until faced with discussion that talks about alt texts. (Maybe not many users set an alt text, I don't know.)

I think VE should either a) delete |alt= when that form becomes blank by actions performed in that form, or b) allow editors to delete the parameter a la the template parameter indicator. Given it's marketed to less experienced users, and deleterious effect if left blank (which is unlike most templates), I'd tend toward supporting a). While alt text can be noisy, and occasionally the default alt text is really noisy, that's better than vanishing the image for the users who need the alt text.

Event Timeline

I agree. When a user types a space in the alt-field, it should be treated as if the field was empty. Then the html output would be the standard fallback of alt="imagename.jpg". Normally, this is not WCAG-conform. But in wikis, there is usually an additional image description which often contains the info that you would expect in the alt attribute.

Good fallback output for missing alt attribute (happens when user does not use the alt text field: <href="link to image page"><img alt="imagename.jpg" src="path/imagename.jpg"></a><div class="thumbcaption">image caption></div>

Bad fallback output for missing alt attribute (happens when user adds a space in the alt text field: <href="link to image page"><img alt="" src="path/imagename.jpg"></a><div class="thumbcaption">image caption></div>
In the second case, the links href attribute can be used by screen readers to indicate where the link goes, so it would read the image.jpg file name out, but it wouldn't be clear that the link is not a text link, but comes from an image on the page.

Blgh, came across another in the wild from 2017 (now fixed). It's really a pernicious problem to be inserting empty alt attributes, or not clearing deleted text from an alt field, when a page is edited. Probably in most cases in the mainspace, this is an undesirable.

At a conservative estimate, we've got somewhere in the realm of 19k pages on en.wp missing some alt text. I've added a request that would have the impact of tightening that number.

There is a solution: T359582 (Define alt=- as intended presentational image).

On template programming there is the identical problem:

  • {{{xyz|DefStd}}} is pointless, this syntax for defaults must not be used.
  • VE users never now whether they leave an empty |xyz= in source text.
  • If there is an empty assignment for |xyz= then the default branch for omitted paramenters is not triggered.
  • VE users cannot decide whether they deal with an empty but existing thing, or something that does not exist. They always see a blank field in forms.

Fields for alt= in image transclusion and gallery forms would need a separated boolean ticbox decorative image which disables the description text field.