@stenajs-webui/elements 23.21.15 → 23.21.16

package/dist/components/ui/buttons/common/BaseButton.d.ts

@@ -4,16 +4,24 @@ import { CommonButtonProps } from "./ButtonCommon";
 export interface BaseButtonProps extends CommonButtonProps, ButtonElementProps {
     forceRound?: boolean;
     /**
-     * Looks and announces as disabled, but stays in the tab order.
+     * Looks and announces as disabled, but stays in the tab order and still
+     * calls onClick.
      *
-     * A button with the disabled attribute cannot be focused, so a keyboard user
-     * never reaches it and is never told it is there. This renders an enabled
-     * button carrying aria-disabled, which screen readers announce as dimmed
-     * while leaving it reachable, and suppresses activation so that it does
-     * nothing when pressed.
+     * A button with the disabled attribute cannot be focused and does nothing
+     * when pressed, so a keyboard user never reaches it and no one can find out
+     * why it is unavailable. This renders an ordinary, working button that is
+     * styled as disabled and carries aria-disabled, which screen readers
+     * announce as dimmed.
      *
-     * Prefer it over disabled when the user needs to find out why the button
-     * cannot be used, such as when it carries a tooltip explaining itself.
+     * The click is the point: it is what lets the button explain itself, by
+     * revealing the errors that are blocking it, or opening the thing that has
+     * to be filled in first. Give it an onClick that says why rather than one
+     * that goes ahead and does the thing the button looks unable to do.
+     *
+     * It is an ordinary button in every other way, so a type="submit" one with
+     * no onClick of its own still submits its form.
+     *
+     * Use disabled instead when the button really should do nothing at all.
      */
     visuallyDisabled?: boolean;
 }