vue-a11y / eslint-plugin-vuejs-accessibility Goto Github PK

I think it would make sense to not report "form-control-has-label" when the given element or one of its parents have aria-hidden="true" set since in those cases accessibility doesn't apply to that element.

This issue might apply to other rules also (maybe all?).

We sometimes have components that combine form elements and labels:

       <label :for="id" ...>
       <input :id="id" ...>

id in this case is a property set on the custom component.

Unfortunately the plugin ignores :for completely and complains about missing for attribute.

We have custom label components.
Currently the label-has-for rule supports custom components to validate as labels.
We need to update the form-control-has-label rule to accept custom label definitions.

I've yet to find any issues, so it may simply be a case of updating peerDependencies to remove the npm install warning.

Looking at the plugin migration guide for 7 -> 8, I don't see any changes that should cause issues here.

When the error show on the rule is the Avoid ARIA if it can be achieved without, it's pretty straight forward what needs to be done to fix it, right? we only would need to delete aria-hidden and/or any "suspicious" role (presentation/none), and insert a alt="" in place of them :D, what do you think?

For "click-events-have-key-events", the element must also be tabbable, right? otherwise there is no point in adding a keyboard event if the element can't be focused, or am I wrong?

Hi 👋🏿

What do you think about creating a documentation site for the library, something very similar that eslint-plugin-vue has?

I think it looks nicer, and easier to navigate than markdown files in GitHub, and would create consistency with other vue libraries' documentation.

Would you accept PRs implementing it? I'm willing to work on this.

Hello, I think the interactive-supports-focus rule is being applied incorrectly to the "tablist" role. According to the ARIA spec, while child elements with the "tab" role should be focusable, there is no indication that the containing "tablist" element must be focusable.

<label class="career-why__dropdown-label">
  <select
    v-model="selectedState"
    class="career-why__region-dropdown"
  >
    <option
      v-for="(acronym, state) in states"
      :key="acronym"
      :value="acronym"
    >
      {{ state }}
    </option>
  </select>
</label>

This fails lint, but it is a valid accessible label/select, or am I mistaken?

The vue-a11y/click-events-have-key-events complains whenever an @click handler is placed on a button without also including @keydown.enter and @keyup.space.

However, adding these listeners to a button, then pressing the enter or space keys will trigger the click event as well, thus firing the event twice.

This has been documented and there is a slightly hacky workaround here: maranran/eslint-plugin-vue-a11y#28

As I understand it, this rule is actually intended for non-interactive elements. So, for example:

<div @click="handler">

Should actually be:

<div @click="handler" @keydown.enter="handler" @keydown.space="handler" tabindex="0">

As I understand, this is not necessary for the button element. Just add the click handler, and the keybaord events for enter and space will fire the click handler as well.

If my understanding is incorrect, please let me know. I'd like to read more about that. If my understanding is correct, then we may want to add some conditional logic to only show this error for non-interactive elements.

The problem is analogical to jsx-eslint/eslint-plugin-jsx-a11y#627, which contains all the details.

TL;DR vuejs-accessibility/accessible-emoji rule should be deprecated and removed from recommended rule lists

The URL in the message for the form-control-has-label rule goes to form-has-label, which responds with a 404

https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/main/docs/form-has-label.md

It should go to https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/main/docs/form-control-has-label.md

<template #label>
  <span aria-hidden>🔽</span>
  Title
</template>
<template #label="{ isOpen }">
  <span aria-hidden>{{ isOpen ? "🔼" : "🔽" }}</span>
  Title
</template>

The above results in this message:

Emojis should be wrapped in , have role="img", and have an accessible description with aria-label or aria-labelledby

If it has an aria-hidden it should skip that message. aria-hidden completely removes the entire element from the accessibility API. So the role and label will not be seen.

The form-control-has-label rule currently looks for input and textinput elements, however custom input components (in our use case, bootstrap-vue's b-form-input component) don't seem to be checked for labels.

Is it reasonable to add a check for an implicit wrapping or explicit id-linked label for custom components? Configurable similar to how label-has-for can be configured to look for custom label components. I don't think deeper inspection (like this plugin does on input to determine eligibility depending on the type of input) is required for custom input types.

I'm using the accessibility plugin, especially the rule label-has-for. My configuration looks like the following:

    'vuejs-accessibility/label-has-for': [
      'error',
      { required: { some: ['nesting', 'id'] } },
    ],

The problem is that the rule doesn't fire when I use it like that:

<label>
  <div></div>
</label>

It only fires when there is no elements in it:

<label></label>

II think the nesting validation rule is broken. I took a look at the implementation and I think this line is incomplete. It should check if there is a form control inside the children 🙂

When using attribute binding to associate the for attribute the plugin does not detect rasies the label-has-for error

This use case is typical when creating enterprise component libraries.

Below is an example of a textbox where the id is being passed as a prop:

<template>
  <div
    class="form-group"
    :class="invalid ?'form-group-error' : ''"
  >
    <h3
      v-if="labeltext"
      class="label-wrapper"
    >
      <label
        :id="`lbl${uniqueid}`"
        class="input-label"
        :for="uniqueid"
      >
        {{ labeltext }}
      </label>
    </h3>
    <div
      v-if="helptext"
      :id="`${uniqueid}-hint`"
      class="govuk-hint"
    >
      {{ helptext }}
    </div>
    <span
      v-if="invalid"
      id="event-name-error"
      class="input-error-message"
    >
      <span class="sr-only">Error:</span> {{ validationtext }}
    </span>
    <input
      :id="uniqueid"
      :name="uniqueid"
      v-bind="$attrs"
     :type="text"
      :value="value"
      :aria-labelledby="`lbl${uniqueid}`"
      :aria-describedby="helptext ? `${uniqueid}-hint` : undefined"
      :autocomplete="autocomplete"
      @input="$emit('input', $event.target.value)"
    >
  </div>
</template>

<script>
export default {
  name: 'Textbox',
  props: {
    uniqueid: {
      type: String,
      required: true
    }
....
}
</script>

Would it be possible to handle this?
Thanks
Bert

As this breaks the forth rule of aria :D

Reference:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute
• https://www.w3.org/TR/using-aria/#fourth

Hello, I have the following vue snippet, where the span needs a tabindex

<div v-for="(row, key) in data" :key="key" class="flex flex-col gap-1 bg-white p-1">
        <div class="flex w-full justify-between align-middle text-navy">
              <span
                     class="text-small cursor-pointer truncate align-middle font-[500] md:text-base"
                      role="button"
                      @click="emitTitleClick(row)"
                      @keydown="emitTitleClick(row)"
              >
                     <span v-if="headers.find((header) => header.title)">
                            {{ row[headers.filter((header) => header.title)[0].field] }}
                     </span>
              </span>
        </div>
</div>

Now, tabindex="0" works, but I want it to assign it based on the index, because more than one will be printed out, but no matter what I try it seems to fail lint validation, eg :tabindex="key", or if i throw index into the loop and use :tabindex="index", so just curious what I am supposed to do in a loop?

Hi everyone!

When it comes to the following issue:
@mouseover, @mouseenter, or @hover must be accompanied by @focusin or @focus for accessibility.eslint[vuejs-accessibility/mouse-events-have-key-events](https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/docs/mouse-events-have-key-events.md)
the reference link mentioned is not available: https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/main/docs/mouse-events-have-key-events.md.

404 - page not found The main branch of eslint-plugin-vuejs-accessibility does not contain the path docs/mouse-events-have-key-events.md.

Thank you for looking into this!

I just realized that linked template are not triggering errors with the plugin ! Am I right or did I miss something in my configuration ? Those linked template should also return accessibility errors.

In my case this kind of configuration does not return any error :(

// Vue file
<script>....</script>
<template src="./template.html" >

// template.html file
<span>👩</span>

Hello,

I am implementing this package on one of my projects but I an running into an issue. I have a radio control component with the following structure:

<label>
  <div>
    <input type="radio" />
  </div>
  <div>
      <slot />
  </div>
</label>

I am receiving an error related to the form-control-has-label rule, even if the input is correctly wrapped into a label tag.

I am not sure if it's related but in my ESLint config I've also added the following rule:

"vuejs-accessibility/label-has-for": [
      1,
      {
        "required": {
          "some": ["nesting", "id"]
        }
      }
    ]

Any hint on how to solve this problem?

Thank you in advance!

This means that if we register a controlComponent as VInput, but use it on our app as v-input, the rule fails, even tho they point to the same component.

A co-worker noticed some inconsistency on when this rule throws an error. In our particular use case, these two versions throw the linting error as expected:

<button @click.prevent="isExpanded = !isExpanded">

<button @click.prevent="toggleIsExpanded()">

However, this one doesn't throw the linting error.

<button @click.prevent="toggleIsExpanded">

This is in Vue 3, for what it's worth.

In our project we translate website into multiple languages and we use a special Vue component instead of a text node inside heading tags. Example:

<h1>
  <Trans tag="hello_world">
</h1>

which in English renders as:

<h1>
  Hello world!
</h1>

The plugin complains about it:

error Headings must have content and the content must be accessible by a screen reader vuejs-accessibility/heading-has-content

Is there a way to implement some exception for specifying which components are allowed to be used inside headings?

Hello there! I just started using this ESLint extension, and I noticed it is flagging a lot of stuff of which I doubt is valid.

I have HTML like:

<div
  @dragover="dragOver"
  @dragleave="dragLeave"
  @dragenter="preventDefault"
  @drop="onDrop"
>

Which will trigger the rule no-static-element-interactions but is that correct? I cannot put a role attribute on this element because there is no role for an element being a valid dropping target. I can of course just ignore that rule in this case but I'm raising the issue here because maybe some event listeners should be excluded from triggering this rule, like the 4 above here.

What do you think?

The makeKebabCase function explodes due to the result of getElementType when dealing with <component :is="foo ? 'a' : 'div'"></component> because the value of is is not a string.

TypeError: value.replace is not a function
Occurred while linting /Users/gavynmckenzie/dev/bbm/patterns/src/components/atoms/PromoSticker/MPromoSticker.vue:24
    at makeKebabCase (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/src/utils/makeKebabCase.js:3:6)
    at getElementType (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/src/utils/getElementType.js:6:10)
    at EventEmitter.VElement (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/src/rules/alt-text.js:108:27)
    at EventEmitter.emit (events.js:203:15)
    at NodeEventGenerator.applySelector (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:3309:26)
    at NodeEventGenerator.applySelectors (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:3323:22)
    at NodeEventGenerator.enterNode (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:3331:14)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:115:13)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:122:21)
    at traverseNodes (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/node_modules/vue-eslint-parser/index.js:133:5)

For example, with Font Awesome Icons, the resulting svg is (by default) aria-hidden, so if they are used inside a button, I want to force people to have an alt text for that button, but at the same time, if FAIcon is used on its own (not inside a button), I do not want to force people to label it (because it won't be visible for screenreaders).

https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/src/rules/label-has-for.js#L9

Like we have an option for custom labels, I want to configure a custom component for the Input 😄

Hello. ✋

I was recently trying out Svelte tutorial and encountered the following error.

A11y: on:blur must be used instead of on:change, unless absolutely necessary and it causes no negative consequences for keyboard only or screen reader users.

It's one where you have to use on:blur if you are using only on:change.

I just remembered that there is a no-onchange rule in eslint-plugin-vuejs-accessibility.

https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/docs/no-onchange.md

By the way, I also looked at the eslint-plugin-jsx-a11y rules, but they are now deprecated.
Please check the details below.

jsx-eslint/eslint-plugin-jsx-a11y#398

As for React.js, it seems that using the onBlur event will cause a warning on the console.

Is it really a problem to just write onChange? I've been looking into it.
In the WebAim discussion, the following is a "mostly" OK response.
https://webaim.org/discussion/mail_thread?thread=8036#post1

In most cases this is actually ok.

I would say, rough estimate, that 80% of onchange events I have seen are ok, 20% are not.

Of the articles referenced in eslint-plugin-vuejs-accessibility, one seems to have an invalid link, and the other link is from around 2004.

It is important to have accessibility measures as a rule, but I think that this rule needs to be updated.

I have two suggestions for the no-onchange rule.

• Treat the rule itself as deprecated (as in jsx).
• Make this rule a warning only, rather than an error (is this possible?)

Of course, this is just my opinion from what I've seen, and I'd like to hear opinions from various people. :-)

Getting a weird issue with form labels. ESLint is complaining:

Form label must have an associated control.eslint(vuejs-accessibility/label-has-for)

But the code is correct:

<label for="email">Email:</label>
<input id="email" name="email" type="email" required />

Am I missing something?

I have a custom switch built with <input type="checkbox">:

<input
  type="checkbox"
  role="switch"
  :checked="isChecked"
>

After enabling role-has-required-aria-props, the following problem is reported:

Elements with the ARIA role "switch" must have the following attributes defined: aria-checked

I believe this is a false positive. <input type="checkbox"> already has its own checked, and I'd think we shouldn't need to replace it with aria-checked. A similar issue was reported for Svelte's ESLint plugin: sveltejs/svelte#7837

Should we consider allowing checked in place of aria-checked?

Hi,

I'm glad this is out there! I'm starting a new project that requires a strong focus on a11y, and this seems like a great way to ensure we don't create a bunch of technical debt we would have to fix later.

I'm starting to test is now, and ran into a small issue. To reproduce, just put <img /> somewhere. The error for missing alt tags comes up, but if you click on it, it goes to this URL, which has an encoded " character at the end:

https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/docs/alt-text.md%22

This could be a VS Code issue, but if so, I haven't seen it so far with other ESLint plugins.

When I init newest my project with the detail

root: true,
  parserOptions: {
    parser: '@typescript-eslint/parser',
    ecmaFeatures: {
      jsx: true,
      modules: true,
    },
    ecmaVersion: 2021,
    sourceType: 'module',
  },
  parser: '@typescript-eslint/parser',
  env: {
    node: true,
    browser: true,
    es6: true,
    jest: true,
  },
  globals: {
    Promise: true,
    process: true,
    console: true,
    Set: true,
    Intl: true,
  },
  plugins: [
    '@typescript-eslint',
    'vuejs-accessibility',
  ],
  extends: [
    'eslint-config-airbnb-base',
    'plugin:@typescript-eslint/recommended',
    'plugin:vuejs-accessibility/recommended',
  ],

Here is the package.json

    "@typescript-eslint/eslint-plugin": "4.22.1",
    "@typescript-eslint/parser": "4.22.1",
    "eslint": "^7.26.0",
    "eslint-config-airbnb-base": "14.2.1",
    "eslint-plugin-vuejs-accessibility": "0.6.1",

I see the error ⬇️. Hope you can take a look! Maybe you need to upgrade deps 🤔.

TypeError: Error while loading rule 'vuejs-accessibility/accessible-emoji': context.parserServices.defineTemplateBodyVisitor is not a function

eslint-plugin-jsx-a11y's label-has-for has recently been deprecated and replaced by label-has-associated-control. This plugin should probably follow suit. I find the default behavior of label-has-for to be confusing, since using both wrapping and a for attribute is redundant. (And for styling reasons, it is often not desirable to wrap <input>s with <label>s.)

Hi, I have a anchor tag that is an icon and, because of that, it has no text related to it. I've made some research and it seems we can use aria-label in scenarios like that. But, adding aria-label to the anchor tag, it still shows the error "vuejs-accessibility/anchor-has-content".

Should this rule consider a valid content, when the tag has aria-label attribute?

Thank you

Hi everyone,

First of all thanks for creating this tool, it really helps too much!

I recently came to an issue about how labels should control the addition of id/for to the combo of label-input.

So, right now the rule only checks if the input is nested inside a label, or if a label has a for attribute but not if the input component has indeed the correct id.

Here is how I define the configuration inside eslintrc:

So you could have a properly created label without an id on the following input like so:

Also the rule complains if the id is set but not the for:

So my guest is that the validate function shouldn't only been looking for the for attribute on labels, but also should be looking for the same string inside the for into the input's id that is nested or following the label node.

I'm based on how W3C tells us how to define properly our form components.

I have a checkbox with a label and extra description. To align the description with the label, I have wrapped them in a div:

<div class="checkbox">
  <input id="myCheckbox" type="checkbox" aria-describedby="myCheckboxInfo" />
  <div class="checkbox-label">
    <label for="myCheckbox">I agree</label>
    <p id="myCheckboxInfo">Here is some extra info what I agree upon</p>
  </div>
</div>

The plugin sees this as a violation of form-control-has-label even though there is a label/@for that refers to the id of the checkbox. The function hasLabelElement only checks the children of the parent but not their children.

I'm wondering about the reasoning for the click-events-have-key-events rule. I would think that having a @click handler is enough in many cases since it will also handle keyboard space & enter when used on interactive (focusable) elements. So why would it be necessary to also add explicit key handlers?

I want to add aria-hidden to the <i>； or replace <i> with <em>；And replace <b> with <strong>

Additional context

Our company uses Sonar to monitor code quality，sonar always tells us the following

The role-has-required-aria-props rule incorrectly flags ARIA 1.1 comboboxes because aria-controls is on the text input and not the parent container with the combobox role.

In the ARIA 1.1 combobox pattern role=combobox is placed on the parent container instead of the text input like in the ARIA 1.0 pattern. Additionally in an ARIA 1.1 pattern, aria-controls is placed on the text input instead of aria-owns. aria-owns is instead on the parent container.

https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.1pattern/listbox-combo.html

Because of the different pattern between 1.0 and 1.1, the role-has-required-aria-props complains because the parent container with the role=combobox does not have an aria-controls attribute.

For instance, this valid ARIA 1.1 combobox markup fails because the div with role=combobox does not have aria-controls:

<label for="ex1-input"
       id="ex1-label"
       class="combobox-label">
  Choice 1 Fruit or Vegetable
</label>
<div class="combobox-wrapper">
  <div role="combobox"
       aria-expanded="false"
       aria-owns="ex1-listbox"
       aria-haspopup="listbox"
       id="ex1-combobox">
    <input type="text"
           aria-autocomplete="list"
           aria-controls="ex1-listbox"
           id="ex1-input">
  </div>
  <ul aria-labelledby="ex1-label"
      role="listbox"
      id="ex1-listbox"
      class="listbox hidden">
  </ul>
</div>

In updating from 0.7.1 to 1.1.0, I started seeing a violation for the vuejs-accessibility/accessible-emoji rule:
Emojis should be wrapped in <span>, have role="img", and have an accessible description with aria-label or aria-labelledby.

It appears that this is being triggered for anywhere that has a copyright symbol, written as ©. I believe this to be a bug, since screen readers are able to read this character.

Vue bootstrap makes use of a parent component that requires a label attribute before it actually has a label. This is currently not enforcable with the configuration options allowed by form-control-has-label

As an example, see this use case:
https://bootstrap-vue.org/docs/components/form-group#label

    <b-form-group
      label="Enter your name"
      label-for="input-horizontal"
    >
      <b-form-input id="input-horizontal"></b-form-input>
    </b-form-group>

[anchor-has-content] with a image with alt fails but it should pass because the alt text serves as content for the anchor

I set alt-text and iframe-has-title, alt-text works, iframe-has-title doesn't work

Where the role attribute is data driven, the linter explodes because it's expecting a string and tried to do .toLowerCase()

I have <div :role="ariaRole"></div> which is eventually a string, but the linter sees it as a Node.

TypeError: roleValue.toLowerCase is not a function
Occurred while linting /Users/gavynmckenzie/dev/bbm/patterns/src/components/molecules/Modal/MModal.vue:55
    at EventEmitter.VElement (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vuejs-accessibility/src/rules/role-has-required-aria-props.js:38:12)
    at EventEmitter.emit (events.js:203:15)
    at NodeEventGenerator.applySelector (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:3276:26)
    at NodeEventGenerator.applySelectors (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:3290:22)
    at NodeEventGenerator.enterNode (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:3298:14)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:113:13)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:120:21)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:120:21)
    at traverse (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:120:21)
    at traverseNodes (/Users/gavynmckenzie/dev/bbm/patterns/node_modules/eslint-plugin-vue/node_modules/vue-eslint-parser/index.js:131:5)

Did anyone already try to add rules for Quasar elements, like an alt-text for <q-img> ?
Would that even be appropriate for this plugin ?

I set custom image component to img props, like this.
https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/main/docs/alt-text.md#rule-details

{
  "rules": {
    "vuejs-accessibility/alt-text": [
      "error",
      {
        "img": [“CustomImage”],
      }
    ]
  }
}

it doesn’t work.

But it work.

{
  "rules": {
    "vuejs-accessibility/alt-text": [
      "error",
      {
        "img": [“custom-image”],
      }
    ]
  }
}

Is it bug?
Please fix code or update rules page.

We're using the v-html attribute to give an anchor its readable contents, but the plugin is only looking for anchors to contain a child element that has inner text.

When an anchor uses v-html or any of its child elements do, that should count as readable content. (Sure, the v-html might return a blank value, but so can a template {{ variable }}).

Details

The Lint rule of anchor-has-content is triggered even if there is an <img> element (an alt attribute is also present).

Version

"eslint-plugin-vuejs-accessibility": "0.5.1"