This reference contains two patterns for required form fields. However, this example in the pattern library uses a hybrid:

<div class="dqpl-field-wrap">
      <label class="dqpl-label dqpl-required" for="required-field">First name</label>
      <input class="dqpl-text-input" type="text" id="required-field" aria-required="true">
      <div class="dqpl-error-wrap"></div>
</div>

.dqpl-label.dqpl-required:after {
    content: 'Required';
...
}

This causes VoiceOver in a modern browser (and possibly other AT/browser combinations) to double announce "required": once for the label text ::after content and again because of the aria attribute. Additionally, the absence of the required attribute may be purposeful, but it's in conflict with the other recommendation.

I think it's best to place aria-hidden or role=presentation on the "required" label text and add the required attribute to the input. If the browser/AT is old and does not support aria/HTML5, then the label text will be read. Otherwise, only the attribute will be announced (and I'm not aware of any AT that double announces for required and aria-required although not all AT honor both).

If this sounds reasonable, I can make a PR.

I see that confirmation toasts are using focus instead of an aria alert role. I'm hearing from other developers (e.g., on the A11Y Slack channel) that shifting focus is "bad UX", and they advocate using aria live regions (e.g., alerts) that disappear after a certain time instead. I honestly don't know which way is better. What is the rationale for relying on focus? Is shifting focus really ok or better for the user than a live region?

looks like we forgot to reattach the blur listener in the mouseup listener

Expected behavior: I can implement a menu item with no submenu items or anchors and write a custom onclick listener for it.

Actual behavior: < ul > and < li > in a project using the dqpl-pattern-library have their click listener propagation stopped by this chunk of code at lines 2736-2758:

 /**
     * Mouse logic for expandable submenu triggers
     */

    (0, _delegate2.default)(elements.menu, '[role="menuitem"]', 'click', function (e) {
      e.stopPropagation(); //THIS IS THE PROBLEM CHILD
      var trigger = e.delegateTarget;

      if (trigger.hasAttribute('aria-controls')) {
        toggleSubmenu(trigger, function (submenu, done) {
          (0, _animation.slideToggle)(submenu, function () {
            var toFocus = submenu.querySelector('[role="menuitem"][tabindex="0"]');
            toFocus = toFocus || submenu.querySelector('[role="menuitem"]');
            done(false, toFocus);
          }, 300);
        });
      } else {
        var link = trigger.querySelector('a');
        if (link) {
          link.click();
        }
      }
    });

Suggested solution: do not stop the propagation of the event if there are no submenu items or anchor. A custom class/property could be a simple implementation has-submenu-or-anchor="false" defaulting to true.

Hi,

Just found a link to this library on twitter and started looking around, was just wondering if there any particular reason you need to disable the button using the class 'dqpl-disabled'? Has that anything to do with accessibility?

<button class="dqpl-button-primary dqpl-disabled" type="button">PRIMARY DISABLED</button>

Asking it, because in the above state the button itself would still fire events, while it looks disabled to the user.

If you set the disabled attribute it would not fire events anymore:

<button class="dqpl-button-primary dqpl-disabled" type="button" disabled>PRIMARY DISABLED</button>

And then you could style it using the :disabled pseudo CSS selector (https://developer.mozilla.org/nl/docs/Web/CSS/:disabled) and button[disabled] (if you need to support older browsers).

Then the following markup would work:

<button class="dqpl-button-primary" disabled>PRIMARY DISABLED</button>

button[disabled],
button:disabled {
....
}

Wondering if the above breaks accessibility in some way, because then I got some code to refactor :-)

Thanks,

Erik

I'm updating our extensions to use a newer version of Cauldron and finding that there is extra CSS preventing a clean switchover. Many All of the classes are prefixed with body .dqpl-layout, which looks like it contains styles for the pattern library site (top: 50px). Those styles shouldn't be applied to things like .dqpl-label, or basic inputs.

For example, this CSS exists on the pattern library demo site, in pattern-library.css:

body .dqpl-layout .dqpl-label {
  display: block;
  text-align: left;
  font-size: 13px;
  font-weight: 300;
  margin-bottom: 4px;
  margin-left: 4px;
  cursor: default;
}
body .dqpl-layout .dqpl-label.dqpl-label-disabled {
  color: #cccccc;
}
body .dqpl-layout .dqpl-label.dqpl-required .dqpl-required-text {
  display: inline-block;
  margin-left: 24px;
  font-style: italic;
  font-weight: 400;
}

All of those things are in use in the Attest extension, but we can't use dqpl-layout. Is there a reason why those are prefixed in that way?

see dequelabs/cauldron-react#82

do you have a version that is compatible with angular 6?

When there's limited horizontal space, the top bar should not have a fixed position. Fixed areas are problematic for low vision users, as they take up a bunch of valuable screen space. I suggest if the height is less than 400px, the top bar should stop being sticky.

I'm still running into the issue from #55:

Can you please create a v2.4.4 release and publish it to npm?

looks like the close button still has dqpl-ftp-dismiss instead of dqpl-ftpo-dismiss

The current position of the menu has a set pixel amount:

If you have a differently sized trigger, this can cause the menu to be offset by an amount that doesn't match the trigger.

We should just be able to use top: 100% to achieve the exact same result.

The section that describes how to set the default selected option of a select component uses an id of "yes" for the aria-activedescendant of the role="combobox" element and the role="option", but has the wrong text content in the element with class="dqpl-pseudo-val". This makes the example misleading.

Adjust the text content of the element with class="dqpl-pseudo-val" to "Yes". I'd do it myself, but these Wikis are under wraps.

• ignore mouse clicks on disabled options

Unstyled buttons have a background color, which can be an issue with icon buttons (see dequelabs/cauldron-react#113 (comment)). We likely want to normalize these for consistant appearance in all browsers.

From demo:
https://pattern-library.dequelabs.com/components/selects

1. select an option from the dropdown
2. click somewhere on the screen to close it, it works when the value is empty

Is there currently a way to use JS to trigger an event when the value changes in a select?
I'm listening to 'blur' events but it triggers even when the value doesn't change.

The wiki currently shows the "require" label in a form field without a space between it and the label. This creates problems for screen readers. I'm not sure what's the best way to do this. I was thinking you might just want to use :before and add inject a space, but you should test if that works with AT.

Ideally, having an option with the innerHTML of x<sup>2</sup> is supported but currently once selected will show up as x2 instead

This will let consumers of the library include the fonts the way that fits their needs

Similar to issue #83 but the inverse...
I'd like to dynamically set the active state of the select.
Is there a way to do this?
Thanks!

.dqpl-select [role="textbox"],
.dqpl-select [role="textbox"]:hover {
  border: 0;
}

...this is how cauldron-react implements the select

dist/js/utils is referenced by pattern-library.js in the same folder but it's not included in the current download from npm (v 2.3.4).

Reported violation: Certain ARIA roles must contain particular children (role="combobox" must contain a textbox)

URL: https://pattern-library.dequelabs.com/components/selects

Disabled buttons show a mouse pointer cursor along with adjusting the shadow depth that makes it appear as the button can be interacted with. As a sighted user, this is confusing since I would not normally be able to interact with disabled buttons.

implement dqpl-fadein-flex-setup which would apply display: flex rather than display: block

Selecting an option and then navigating through the options will repeatedly announce the selected one before the currently focused one

moving cauldron-react here too. We'll end up with:

• packages/cauldron-styles
• packages/cauldron-js
• packages/cauldron-react

This will be breaking backwards compatibility because the base class fa is now separated into fab, fas, far, and fal

A simple change could be using actual input[type=radio] and input[type=checkbox] elements and keep the appearance identical using aria-hidden overlaying elements

When using the keyboard to navigate a topBar dropdown and there are at least 3 options within the dropdown. The keydown goes to the prev option (bottom of list) not the next option (below).

Initial opening of menu

After pressing down arrow

In attempting to setup a quick demo for someone, I quickly realized how hard it is to position all of the parts (wrapper, box, arrow etc..) of the ftpo. Shortly after flailing for a bit, I realized that simply applying position: absolute; to the dqpl-pointer-wrap styling became easy 😄

IMO, dqpl-pointer-wrap should be position absolute by default and allow implementers to change it if needed (99% of ftpos I've seen in the wild are positioned absolutely)

if an option menu is open and user clicks tab or shift+tab, the menu should close

The engines field in this library'spackage.json is too strict. I'm unable to install it without errors.

Environment details:

Installation output:

 ∴ yarn init -y
yarn init v1.3.2
warning The yes flag has been set. This will automatically answer yes to all questions which may have security implications.
success Saved package.json
✨  Done in 0.03s.

 ∴ yarn add deque-pattern-library
yarn add v1.3.2
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version "8.1.3".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

I should be able to:

const mySelect = document.querySelector('.dqpl-combobox');
const e = new Event('dqpl:combobox:options:refresh')
mySelect.dispatchEvent(e); // tell this specific combobox to reassess dynamically added options

NOTE: Backwards compat will be broken once #86 and #85 are resolved

In the modal views, the font icon character for the close button is exposed to AT; need to hide to ensure AT doesn't output the character (as there's already alternative text provided).

<button class="dqpl-close" type="button">
  <div class="fa fa-close">::before</div>
  <div class="dqpl-offscreen">Close</div>
</button>

Recommend:

<div class="fa fa-close" aria-hidden="true">::before</div>

https://pattern-library.dequelabs.com/composites/modals

I believe the Selects Component might include an incorrect role. It currently features role="combobox", and according to ARIA Authoring Practices 1.1, a combobox is made up of a text input and a list of options, much like an autocomplete component.

When listening to the role descriptions, this component is announced as, "combo box," whereas a native select element is announced as "popup button" (VO + Safari at least.)

When reviewing the "single select" Collapsible Dropdown Listbox demo, which features a button element and aria-haspopup="listbox", this seems to accurately announce the role as one might expect.

Should this component's role be changed from combobox to button and include the aria-haspopup="listbox" attribute to ensure an accurate description? 🤔

When moving through the options with the keyboard in Chrome, the selected item is not announced in VoiceOver

When the main content receives focus, instead of the purple focus ring, it has a bar on the left. This is actually much nicer, and it would be nice if this behaviour could be used on other elements as well. I think we need an option for that bar being inside or outside the focusable element.

...by adding pointer-events: none;

right now the tooltip gets created once and doesn't update even if the [data-help-text] attribute gets updated. Makes most sense to reassess every time the tip is displayed (

Example:

A modal is opened with a Select (role=combobox) child. When the user expands the Select, "Escape" should collapse it (but not the modal). If the Select has focus and is collapsed, "Escape" should bubble up to close the modal.

A problem is caused by the modal when it has siblings (especially flex-box scenarios) because it takes up space. When it is shown, and it's display property changes, it shifts the siblings appearing behind the open dialog.

Suggest adding position: absolute to the .*-dialog-show

see https://github.com/dequelabs/walnut/issues/362