16

A recent change in the CSS of the Share button under posts has the pointer turning into a stop (or forbidden) sign if you hover over the link.

(I wasn't able to take a screenshot containing the cursor so I copy-pasted one over the screenshot to give an idea of what it looks like).

hover over link of share button

Is this change part of the previously announced upcoming changes aimed at improving accessibility? (The announcement says the changes would be rolled out on SO and Teams.)

This change causes some difficulty in reading the link if you want to select a part of it on some systems. It might also not be the best choice semantically and in terms of UX.

Using Windows 10, Firefox 104.0.2 (64-bit), 1920x1080. rev 2022.9.13.42974

Improve this question
16
  • 1
    Able to reproduce as well. Suspect it's a change in the Chromium core to put the symbol when hovering over non-editable text fields.
    – Sonic the Anonymous Hedgehog
    Commented Sep 13, 2022 at 23:50
  • 1
    Repro here too on Brave (Chrome core).
    – W.O.
    Commented Sep 13, 2022 at 23:51
  • 5
    @W.O. the screenshot was taken on a post with an older license that hasn't been edited since.
    – bad_coder
    Commented Sep 13, 2022 at 23:55
  • 3
    @SonictheAnonymousHedgehog I went ahead and tested that theory but didn't get that symbol in an html file I created. Then I inspected the share textbox in chrome and it looks like stacks.css specifically adds the not-allowed cursor for .s-input[readonly]
    – Cave Johnson
    Commented Sep 13, 2022 at 23:57
  • @CaveJohnson Huh, didn't see that. I guess since it could be an intentional change given that it's explicitly in the file, I'm retagging this as a possible-bug (synonym of support).
    – Sonic the Anonymous Hedgehog
    Commented Sep 14, 2022 at 0:08
  • 2
    If you feel this is a bug, then what cursor do you think it should use? While the input is readonly, the text can still be selected, both fully and partially, copied, and/or dragged to into an appropriate drop target.
    – Makyen
    Commented Sep 14, 2022 at 0:20
  • @Makyen I think it's a bug because formerly the usual select cursor was shown. Other fields that aren't directly editable (e.g. texts in posts, etc) also use the selection cursor.
    – bad_coder
    Commented Sep 14, 2022 at 0:23
  • 7
    The problem with using the not-allowed cursor here is that it makes it less obvious where I'm going to start selecting text. A common avenue for me when I do not want to include my user Id is to start selection before the Id and drag left to select the remainder, which is benefited by the default text select cursor. It's much harder to do that with a circle.
    – animuson StaffMod
    Commented Sep 14, 2022 at 0:25
  • @animuson I agree, and I use the field the same way you describe. I'm starting to think this might be an accessibility change..?!
    – bad_coder
    Commented Sep 14, 2022 at 0:27
  • 5
    Incidientally the not-allowed cursor in mac is much better and still shows a pointer: i.sstatic.net/WC0CU.png
    – Cave Johnson
    Commented Sep 14, 2022 at 0:31
  • 1
    @bad_coder I wasn't indenting to imply that the current cursor is the ideal one to use. I was trying to suggest that your "question" here is unclear. All your question does is make a statement about "this thing is". It doesn't give any indication as to why you want us to know that, why it's something we should care about, indicate that something is wrong, non-optimal, or indicate that something should be changed.
    – Makyen
    Commented Sep 14, 2022 at 0:35
  • 6
    If I was going to pick from the available options, I'd think that either cursor: copy or cursor: text would be the most appropriate, with copy probably being the most semantically accurate. OTOH, cursor: text is the one with which people are most familiar. Both options have drawbacks. IMO, the real problem is that the <input> element is being used for something which is, in no way, intended as an input.
    – Makyen
    Commented Sep 14, 2022 at 0:42
  • 8
    @Makyen That's a very good point. I was trying to think of how this would be an "accessibility" change. But the real accessibility improvement here would be to display it as plain-text (maybe styled to look similar to an input, but plain-text nonetheless) and not in an input where we aren't ever expecting any input. Most articles I've ever read would say this is an inappropriate use of readonly in the first place.
    – animuson StaffMod
    Commented Sep 14, 2022 at 1:13
  • 1
    @CaveJohnson in general it is fine as it means "you can't edit this", however when the whole purpose is to copy the text, it's common sense to override this with the default cursor instead, so people can copy it. They might have had such override rule for the share-this link, that got lost somehow, hence a bug.
    – Shadow Wizard
    Commented Sep 14, 2022 at 10:25
  • 1
    @ShadowTheKidWizard yep, I agree. I didn't mean to say that the not-allowed cursor is correct (just that the mac cursor slightly more helpful than the windows version). In fact, it looks like it's telling the user "you are doing something wrong" when they are simply trying to highlight and copy the text.
    – Cave Johnson
    Commented Oct 3, 2022 at 22:18

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .