Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There is no way to exclude areas in all iframes based on a selector #130

Closed
dylanb opened this issue Sep 6, 2015 · 6 comments
Closed

There is no way to exclude areas in all iframes based on a selector #130

dylanb opened this issue Sep 6, 2015 · 6 comments
Labels
core Issues in the core code (lib/core)

Comments

@dylanb
Copy link
Contributor

dylanb commented Sep 6, 2015

for example, if I only want to analyze form fields outside <form> elements, then I have no way to specify the exclude in such a way that it will work in a multi-frame document.

@dsturley
Copy link
Contributor

dsturley commented Sep 8, 2015

Just exclude the frames?

@dylanb
Copy link
Contributor Author

dylanb commented Sep 8, 2015

Thing is I want to analyze the content outside all the forms in all the frames

@dsturley
Copy link
Contributor

dsturley commented Sep 8, 2015

This looks like a bug. GitHub was inserting a line break in place of the <form> reference, which totally changed the meaning of that sentence... I was so confused. Would test tests cover your use case?

We may want to refactor (i.e. break) the Context parameter to drop support for the CSSSelectorArray. Context would support, include and exclude given the following parameters:

  1. The typical accepted parameters (jQuery-like support)

    1. A direct Element reference
    2. Array-like structures that references actual DOM nodes (NodeLists, jQuery objects, etc)
    3. String selector
    axe.a11yCheck({
      include: 'input, textarea, select, etc',
      exclude: jQuery('form') // direct reference, will only exclude forms in current frame
    }, function () {});
  2. Constructed CSSSelectorArray object. It would be constructed by calling a utility. This would allow us to remove the ambiguity of "Is this object not an Array, but Array-like, but also not string but not an Array that contains an Array of strings?".

axe.a11yCheck({
  include: 'input, select, textarea, etc',
  exclude: axe.util.elementLocatorThingy([
    'iframe.crazy',
    'iframe.long',
    'iframe.selector',
    'div.thingy'])
}, function () {});

@dsturley
Copy link
Contributor

dsturley commented Sep 8, 2015

Another problem is that currently including specific areas exclude iframes that are outside those areas. The input, select, textarea example highlights this nicely. A user might be expecting to see all form inputs in all frames, but will only get them in the top frame.

@dylanb
Copy link
Contributor Author

dylanb commented Sep 9, 2015

I don't like totally blowing away the current specific selector for the following reasons:

  1. totally breaks the current API, and
  2. means that we cannot pass an address from one of our issues back into the API

We could fix #2 by making our addresses this new type of object but that breaks the API even more.

Why don't we just add a simple string selector to include and exclude that would always be interpreted as being executed in all frames?

We could mix this with selector arrays to achieve any targeting we want.

Example: analyze only in my main content area inside all <form> elements (in all frames)

{
    include: [
        ["[role='main']"],
        "form"
    ]
}

Example: Analyze in all <form> elements (in all frames) but not inside the irritating survey popup thingy

{
    include: ["form"],
    exclude: [["iframe.foresee"]]
} 

Example: Analyze everything in all frames except the reviews from that third party review provider (in all frames)

{
    exclude: [".bv-extensions-panel"]
}

felixzapata pushed a commit to felixzapata/axe-core that referenced this issue Aug 13, 2016
KSD-464 do not report on disabled inputs / buttons
@WilcoFiers WilcoFiers added the core Issues in the core code (lib/core) label Apr 17, 2018
@WilcoFiers
Copy link
Contributor

3 years since this issue was opened, and I have yet to see a single use case for it. I'm going to assume this isn't a problem for anyone and close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues in the core code (lib/core)
Projects
None yet
Development

No branches or pull requests

3 participants