終了コードが0のときに，何も表示されずに終了してしまいます．
なにか表示してほしいかも！

• Core implementation
• CLI
• Web backend
• Web frontend

• update domain model
• bump version
• capture feature
• GHってどんなデータ構造でdiffを保存してるんだろうか

要件 Requirements

Detailed Reasons for Errors

エラーの詳細な説明。なぜダメなのかの理由も加える。 related to #20

Diff views

diff hunkを使ってどの行にどういうpatchを当てればよいか教えてくれる。github reviewに近い概念モデル

References

provides external links or hints for further information. such as a webpage of w3c

It is painful to await every time when i want to use t. I should’ve used initImmediate instead.
https://www.i18next.com/overview/configuration-options

i18next を引き回すのがだるすぎるので、できればデフォのインスタンスを使いたい。無理ならinitをawaitせずにcreateInstanceしたじてんでreturn

Hi 👋

I want to try visible via CLI but install @visi/cli was failed. The @visi/cli/dist/index.js was not included at published directory.

$ npm i -g @visi/cli
npm ERR! code ENOENT
npm ERR! syscall chmod
npm ERR! path /usr/local/lib/node_modules/@visi/cli/dist/index.js
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, chmod '/usr/local/lib/node_modules/@visi/cli/dist/index.js'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent 

Now latest version is 0.0.1-rc1.
I hope that this project becomes more bigger and tell people importance of accessibility in web. Thank you!

It might be needed to grasp the concept of Design System. I'm gonna use either styled-system or xstyled for the consistency of API

Current Issues

• Since Node.js and the browser processes are completely independent, we cannot send/receive any data but JSON-serializable ones.
• Thus even if you could resolve plugin names from a config, we cannot send the module to the browser.

API draft

import { Rule } from "@visi/core";

export default {
  config: {},
  rules: [],
};

class MyRule extends Rule {
  audit(options = {}) {
    const config = this.getConfig();
    return {};
  }

  fix(options = {}) {
    const providers = this.getConfig().providers;
    return {};
  }
}

By using aggregation concept from DDD I can use transaction feature of SQL with abstraction

Aggregation Roots

• Source
• Rule
• Diagnosis
  • Report
    • Location
    • Pointer

in the future..

• Rule
• Diagnosis
  • Source
    • Report
      • Location

Milestones

• language
• viewport
• User-Agent
• rendering engine

Currently, we cannot resolve rule by names (requires new) so it is needed to add static properties to rules.

• Level of error
• Enable plugin per rule

core package depends on some external packages which required to be installed to node_modules. Because I did not declare these external packages explicitly, Rollup warns about it when compiling.

I think this is a kind of boilerplate of rules which should avoid.

return {
  ...
  xpath: createXpath(element),
  css: getComputedStyle(element),
  html: element.outerHTML,
};

Look of the API

It would be useful if I can implement fixer by using AST rather than the DOM because the problem is not always caused by the DOM, sometimes we may need to fix CSS issues too. So AST fixer may provide a consistency.

fix(ast: Node) {
  ast.push(anotherNode);
  return ast;
}

Provider

For fixing issues such as img-alt, we need to provide the way to convert media to another form. We do not guarantee that there's a matched provider because they're all optional.

interface Provider {
  imageToString(url: string): string;
}

class Rule {
  fixer() {
    this.provider.imageToString(...);
  }
}

できればASTとかwalkerとは疎結合にしたい & 言語またいで共通のAPIを提供したいけど、コスト高そう。

プロトコル間でASTのインスタンスを渡すのは難しいから、やっぱりpluginの仕様を考え直したほうが良いかもしれない。ソースコードを持てるのはNode.js側だから自ずとNode.js側にfixerが属することになる。

もしくは抽象化した操作だけを提供するとかかなぁ。

• Revert ESLint / stylelint cache directory

ほんまか？要検討

Workaround

mkdir ./tmp

ソースがpackedされてたりすると起きる問題かもしれません．

@kyasbal-1994 さんに未踏ジュニアの面談で訊かれたので

JSX Pragma

JSX Pragma（マジックコメント）でJSXを解釈する関数を入れ替えられる、emotionとかがやってる方法がある

そいつをファイルの先頭につけてマウントすれば、visible側でReactのマウント処理をフックできるから、マウント先のDOM⇆マウントされたJSXがマッピングできるはず

ネックになりそうなのはそのJSXをどうやって.jsxに紐づけるかだけど、CDPにスタックから元のファイルの行数を調べる機能があったはずなので、

1. visibleでJSXの先頭にJSX PragmaをつけてReactの処理をフック
2. ルール実行、レポートには普通にXpathでDOMの位置を書く
3. Postprocessorとして、XpathからDOMを探して、DOMがキャッシュしてるマップにヒットするか確認
4. ヒットしたらその関数のスタックを見て元のjsxの行数を当ててる（たぶん開発者ツール同様にソースマップも効くはず）
5. レポートのpointerプロパティを書き換える

• WCAG 2.1 @visi/config-wcag
• WAI-ARIA 1.1 @visi/config-wai-aria
• HTML 5.2 @visi/config-html
• EPUB Accessibility 1.0 @visi/config-epub
• BBC HTML Accessibility Standards v2.0 @visi/config-bbc

• Rule Identifier
• Rule Description
• Rule Type (Atomic/Composite)
• Accessibility Requirements Mapping #21
• Rule Input
• Applicability
• Expectations
• Accessibility Support
• Test Cases
• Changelog
• Glossary

W3C example

https://www.w3.org/TR/act-rules-format/#appendix-data-example

1行が長いから発生している？

• search系メソッドでcloneしたオブジェクトを返す
  • いいけどHTMLのdomhandlerが無理そう
• 差分を毎回取る
  • 本質的な解決にならない

あああ

Puppeteer automatically recognize that env var by default https://github.com/puppeteer/puppeteer/blob/master/docs/api.md#environment-variables

• browserの実装としてできる？？

Alike ESLint, it helps to improve the productivity of developing Visible plugin if there's some generator.

Decoupled components of web-ui is being not rendered, since Babel does not compile modules from node_modules and this means we cannot use styled components plugin of Babel

We can fix this problem by compiling packages from node_modules by nextjs’ Babel