• WTFGuy (unregistered)

    Frist we'll do the needful by fixing those names in the obvious way:

    // IsNotEnabled and IsNotDisabled are two different concepts.
    // IsNotEnabled affects whether the element can be focused. If true it cannot not be unfocused.
    // IsNotDisabled affects the visual look of the element. 
    // while not disallowing it to still be focusable for accessibility purposes. If true it cannot not be non-accessable.
    
  • NotAThingThatHappens (unregistered)

    I have some experience doing UI-testing with 'Windows.System.Automation'. 'Automation' relies on the accessibility framework.

    If you use it to look-up an 'Control' that is 'Disabled' (Enabled-property=false), then 'Automation' will not find it. So it becomes impossible to determine if the control is 'un-visible' (grin) or just 'un-selectable'.

    I completely and (through my work) intuitively understand the differences mentioned in the article, and the need to render a control in 'Disabled state' while being 'Enabled'.

  • (nodebb)

    No mention of whether the control can be clicked (button) or edited (text box). There's probably another property for that, IsUsable.

  • Sauron (unregistered)

    As bad as it is, it is still a documented WTF.

    That being said, without the rest of the code we can't tell whether the comment itself accurate or completely false.

    Tell me, it is accurate, right? Right?

  • (nodebb)

    Basic ADA...... If a control can not be focused on, screen readers (and other tools) have problems identifying it as a "piece of information" that must be conveyed to the user as it is something where the content may have changed since the last time it was "read".... Now, there are certainly better words, but one must also e careful of overloading terms, and "Enabled" already has a pre-established context And setting enabled to false can lead to ADA violations.

    TRWTF is how few developers properly test their applications for ADA compliance. And few understand the penalties for being non-compliant, and though they are rarely broadly applied, at the letter of the law, thy could bankrupt many firms.

  • (nodebb) in reply to WTFGuy

    I don't think you have done that right. There's still too much confusing consistency.

    // IsNotEnabled and IsDisabled are two different concepts.
    // IsNotEnabled affects whether the element can be focused. If true it cannot not be unfocused.
    // IsDisabled affects the visual look of the element. 
    // while not disallowing it to still be unfocusable not for inaccessibility purposes. If false it can not be non-accessable.
    
  • (nodebb)

    The combination of "IsEnabled" and "IsDisabled" are terrible names for these distinct concepts.

    However, WPF (which I worked on 10 years ago) similarly had two distinct properties, where a control had both "ReadOnly" and "Enabled" properties. The latter would not allow UI interaction (including tab focus) while the former would, I never worked on WinForms, but I wouldn't be surprised if it was the same.

  • Bitboy (unregistered) in reply to TheCPUWizard

    This.

    I spent several years supporting Accessibility in a large enterprise application (technically, this part's covered under section 508 of the Rehabilitation Act, not ADA). The way most screen readers work is that, in order to convey relevant info (control type, caption, and state) to a visually impaired user, the user has to be able to set focus to that control (usually by tabbing into it). An unimpaired user can see a disabled checkbox on the screen with an associated label that says "Enable Section 508 Functionality". JAWS (and all other screen readers that I know of), will just tab right over the top of it, and a visually impaired user will never even know that it's there, much less what it says or what other state may be applied to it.

    Our application checked to see if JAWS was resident in memory, and, if so, went through and completely changed the UI to ensure that JAWS could read the controls correctly. Frequently by doing things like adding an additional label or static text control BEHIND the disabled checkbox that COULD receive focus and said something like "Enable Section 508 Functionality Checkbox Disabled" just to ensure that JAWS could find it.

    I suppose that TRWTF here is that JAWS, at least, has been around for at least 15 years that I know of and still hasn't come up with a reasonable way to read disabled controls that won't require a developer to do silly gymnastics to ensure that the control can be read.

  • (author)

    Naming is hard. But it doesn't help when you name things using some kind of metaphor that isn't what you really mean. If you have to write a comment that says "IsEnabled means can this element be focused on?" then just NAME IT WHAT IT MEANS, instead of making the reader do mental gymnastics for the next twenty minutes. canFocus. canSee. canDo.

  • (nodebb)

    Off topic -- I have a bookmarklet that makes Remy's comments visible. (He used to do much more extensive comments; now we're lucky if he does a two-word EASY READER version.) I got the bookmarklet from this forum somewhere.

    document.getElementById('article-page').innerHTML = document.getElementById('article-page').innerHTML.replace(/<!--\s*/g,'<--').replace(/-->/g,'-->');

    The weird thing is: if I run this javascript from the console, it very nicely just makes the comments visible in yellow. If I run it from a bookmarklet, the whole page loses its CSS. See screenshots: https://imgur.com/a/jIb6Psl

    Firefox 107.0.1, Windows 10 Enterprise.

    Anyone know why?

  • (nodebb)

    Our application checked to see if JAWS was resident in memory

    Please don't do this. It's not that different from browser sniffing, and has the same risks. For one, JAWS isn't the only screen reader software commonly used, even just on Windows.

  • Sole Purpose Of Visit (unregistered) in reply to Jonathan Lydall

    Basically, WinForms is the same.

    It's incredibly confusing to bears with very little brain, such as me. WinForms makes it worse, because (I'd have to look which way round) one of ReadOnly and Enabled is actually under the sub-class "Properties" ... and the other one is not. I'm not even sure this is consistent across all controls. I try to avoid thinking about it, to be honest -- auto-complete is my friend.

  • Bitboy (unregistered) in reply to jkshapiro

    Understood, but JAWS was the only screen reader we support. There was at one point some effort to start supporting NVDA, but it ended out coming to naught. Anyone in the organization who needs visual AT gets JAWS whether they like it or not (unless they're running a Mac: as bad as some of Tim's stuff is these days, Apple was really doing AT right the last I looked).

    And as far as it being a bad practice akin to sniffing browsers, yeah: I can't really defend it other than to say that the alternative was worse.

  • Argle (unregistered)

    I had trouble breaking students of the habit of writing:

    int x; // an integer named x

    Would you believe other professors encouraged this? This is part of why we're in trouble.

  • a cow (maybe a robot-cow?) (unregistered) in reply to Sauron

    "That being said"?

    Or did you mean "that being sad"?

  • MaxiTB (unregistered) in reply to Lyle Seaman

    Nah, it really isn't. If this it dotnet, the naming convention for boolean properties was Is + <Adjective> like IsEnabled. However having both a positive and negative is kinda stupid, if it doesn't do, well, the opposite, which makes it redundant. The other one should have been IsReadOnly or something.

  • Randal L. Schwartz (google)

    I asked ChatGPT to fix it. First time I ever got a shrug emoji.

  • Nicholas (unregistered) in reply to Ross_Presser

    You are missing the void statement and are instead replacing the whole document with just the inner html of that element. The bookmark should be like javascript:void( your code here );

  • Ollie Jones (unregistered)

    This looks to me like a consciencious maintainer of the code did the WTF? WTF!? WTF)*)$%@! digging for us, and did their hard best to explain the code they inherited to the next maintainer.

    Pretty cool to see that.

  • (nodebb) in reply to Lyle Seaman

    If you have to write a comment that says "IsEnabled means can this element be focused on?" then just NAME IT WHAT IT MEANS, instead of making the reader do mental gymnastics for the next twenty minutes. canFocus. canSee. canDo.

    noCanDo.

  • (nodebb) in reply to Bitboy

    @Bitboy - yes, I was taking linguistic shortcuts. I have not kept (that close) of an eye on the regulations over the past 3-5 years (before that I lived in them), but requiring a specific set of tooling might incur some unwanted side effects. The two bigget ones I encountered were:

    1. people filing civil suits that ehy could not be hired because the job would require the use of certain software.
    2. companies losing contracts dur to the prohibition of use of governmet funding (certain classes) in environments that were in violation.
  • KLEVA (unregistered)

    The way I understand this: The user meant this for literally a Disabled person. Therefore isDisabled might allow some software to be able to select the value and read it out to the user. So isDisabled could be renamed to isVisuallyImpaired?

  • WTFGuy (unregistered)

    @TheCPUWizard: It sounded to me like @Bitboy's app was in-house only. Your concerns are 100% valid for something open to the public, but not so much for in-house stuff where management controls all the clients. A quaint idea nowadays, but not so much back in the day.

    I too used to deal w Sec. 508 for both in-house and public-facing gov't-operated websites. A royal PITA with the tools of the day vs. the vague open-ended nature of the Sec. 508 language and rather little case law to establish how much "reasonable" was enough "reasonable".

  • (nodebb) in reply to Argle

    I had trouble breaking students of the habit of writing:

    int x; // an integer named x
    

    Would you believe other professors encouraged this? This is part of why we're in trouble.

    I would believe it, but it is still awful... If you mean it literally, this is pretty much the teaching example of a useless comment.

    Same as

    #define FIVE 5.0
    

    is a teaching example of "guideline misapplied".

  • Nobody (unregistered)

    So why does this terminology remind me of JavaScript´s blur/onblur referring to the opposite of focus?

  • (nodebb) in reply to Nicholas

    Thank you! This was exactly right. I guess this proves how little I know about javascript? Or browsers? Something.

  • JaiBabaKedar (unregistered)
    Comment held for moderation.
  • Champs (unregistered)
    Comment held for moderation.
  • Gnasher729 (unregistered)

    “Accessibility” is about disabled people. A blind person would want to know that a disabled option exists, so even though it cannot be used, the ui element must be there and must be read through a screen reader.

    Or let’s say you can use arrow keys to select different buttons. You know it’s two tabs from button 1 to button 3. You don’t care about button 2. It would be a pain if you had to know whether button 2 isn’t enabled because suddenly two tabs goes from button 1 to button 4.

    The naming is obviously atrocious and dangerous.

Leave a comment on “Enabled and Disabled”

Log In or post as a guest

Replying to comment #:

« Return to Article