icon page includes (Default) in alt text for ALL icons #1703

Closed
kareila opened this Issue Feb 24, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@kareila
Member

kareila commented Feb 24, 2016

Reported here: http://www.dreamwidth.org/support/see_request?id=32773

Verified on the reporting user's icons page which uses journal style, and on my own account's icons page which uses site style.

@pinterface

This comment has been minimized.

Show comment
Hide comment
@pinterface

pinterface May 19, 2016

Contributor

Might as well claim this, since I'm staring at the code.

It seems to be an issue of LJ::Userpic->alttext always including "(Default)" (not translated, naturally) if a keyword string is not passed in, and LJ::S2::IconsPage not passing in a keyword string. However, I'm not really clear on what the correct behavior /is/.

Near as I can puzzle out, LJ::Userpic->alttext was written with posts and comments in mind--that is, there's only one applicable userpic keyword, or there is none (fallback to default).

So what happens when that interacts with something like the /icons page is...well, things go weird. "(Default)" in alt for every icon is only one example. Another example would be the title attribute, which lists one and only one of the keywords which applies to that userpic. If you're viewing by "Keyword Order", the keyword listed in title may not even be the same keyword the userpic is being displayed for (it'll be a different keyword also applied to that image).

There's also the autogenerated keywords (pic#$id) to be considered (filter out? include?). And possibly whether the information needs to be in the alt attribute at all: it's already next to the image on the page.

In other words, the desired behavior should probably be specced out.

Contributor

pinterface commented May 19, 2016

Might as well claim this, since I'm staring at the code.

It seems to be an issue of LJ::Userpic->alttext always including "(Default)" (not translated, naturally) if a keyword string is not passed in, and LJ::S2::IconsPage not passing in a keyword string. However, I'm not really clear on what the correct behavior /is/.

Near as I can puzzle out, LJ::Userpic->alttext was written with posts and comments in mind--that is, there's only one applicable userpic keyword, or there is none (fallback to default).

So what happens when that interacts with something like the /icons page is...well, things go weird. "(Default)" in alt for every icon is only one example. Another example would be the title attribute, which lists one and only one of the keywords which applies to that userpic. If you're viewing by "Keyword Order", the keyword listed in title may not even be the same keyword the userpic is being displayed for (it'll be a different keyword also applied to that image).

There's also the autogenerated keywords (pic#$id) to be considered (filter out? include?). And possibly whether the information needs to be in the alt attribute at all: it's already next to the image on the page.

In other words, the desired behavior should probably be specced out.

@rahaeli

This comment has been minimized.

Show comment
Hide comment
@rahaeli

rahaeli May 19, 2016

Contributor

Hmmm. My gut instinct is to say that yeah, alt and title should be blank (not missing, but "alt="" title=""") for the /icons page, since yeah, the information that would go into the alt/title is right there next to the icon on the page. I am completely willing to be overridden there, though, because I am not a screenreader user. @deborahgu -- thoughts? (Alternately, I can ping one of my screenreader-using friends to get her opinion.)

Contributor

rahaeli commented May 19, 2016

Hmmm. My gut instinct is to say that yeah, alt and title should be blank (not missing, but "alt="" title=""") for the /icons page, since yeah, the information that would go into the alt/title is right there next to the icon on the page. I am completely willing to be overridden there, though, because I am not a screenreader user. @deborahgu -- thoughts? (Alternately, I can ping one of my screenreader-using friends to get her opinion.)

@rahaeli

This comment has been minimized.

Show comment
Hide comment
@rahaeli

rahaeli May 19, 2016

Contributor

or, you know, I could ask dw-accessibility.

Contributor

rahaeli commented May 19, 2016

or, you know, I could ask dw-accessibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment