diff --git a/.github/workflows/markdown-lint.yml b/.github/workflows/markdown-lint.yml index a1c71c39ac50f44..f744ad5912a326a 100644 --- a/.github/workflows/markdown-lint.yml +++ b/.github/workflows/markdown-lint.yml @@ -6,7 +6,6 @@ on: - main paths: - '*.md' - - 'rfcs/**/*.md' - .github/workflows/markdown-lint.yml diff --git a/files/en-us/web/accessibility/aria/roles/tab_role/index.md b/files/en-us/web/accessibility/aria/roles/tab_role/index.md index 724ea760f1f80c6..8b62b387307252f 100644 --- a/files/en-us/web/accessibility/aria/roles/tab_role/index.md +++ b/files/en-us/web/accessibility/aria/roles/tab_role/index.md @@ -214,8 +214,6 @@ It is recommended to use a {{HTMLElement('button')}} element with the role `tab` What are the related properties, and in what order will this attribute or property be read, which property will take precedence over this one, and which property will be overwritten. -Screenreader support is still to be determined. Visit https://github.com/mdn/content/blob/main/rfcs/aria-roles.md for more information. - ## Specifications | Specification | Status | diff --git a/rfcs/README.md b/rfcs/README.md deleted file mode 100644 index 9b2111c415417ac..000000000000000 --- a/rfcs/README.md +++ /dev/null @@ -1,45 +0,0 @@ -# MDN RFCs - -MDN RFC (Request for Comment) documents are intended to concisely summarize a -proposal for a larger work item that we should consider doing on MDN. This -includes what problems are being solved by the work, what benefits it brings to -MDN and the wider web industry, how much effort it will take, and what the -work involves. - -Once submitted, RFCs are used to assess and prioritize upcoming MDN work. They -are considered as part of our [Content opportunity assessment](https://developer.mozilla.org/en-US/docs/MDN/Contribute/Processes/Workstream_assessment_project#content_opportunity_assessment) -process. - -## What should the RFC contain? - -The RFC should contain the following: - -- A title and opening paragraph that summarizes the work proposed by the RFC. -- Problem statement: A paragraph that explains why we should do this work, in - the form of a problem statement — a problem that MDN/the web industry - currently faces, and what we should do about it. -- Priority assessment: A list of criteria that each RFC is assessed against, - with a description of how the RFC scores against each one. This section uses - the [OWD prioritization criteria](https://github.com/openwebdocs/project/blob/main/steering-committee/prioritization-criteria.md). -- Proposed solutions: At a high level, what solution or solutions are being - proposed to fix the problem stated earlier? -- Task list: A lower-level set of tasks that would need to be completed to - implement the solution(s) detailed above. This obviously can't be 100% - accurate at the planning stage; rough ideas are fine for now. - -When creating a new RFC, use an existing RFC as a template. - -## Submitting an RFC - -Submit your RFC as a markdown file in this directory of the `content` repo, -as a PR. - -## Getting feedback - -Once written, an RFC document should be sent around to key stakeholders that -can provide the most valuable feedback on the document, for example MDN core -writers or engineers, [MDN PAB](https://developer.mozilla.org/en-US/docs/MDN/MDN_Product_Advisory_Board) -members, [Open Web Docs](https://github.com/openwebdocs/) members, writers of -associated technology specifications, etc. - -The MDN team are happy to help you with this; feel free to ask on submission. diff --git a/rfcs/aria-roles.md b/rfcs/aria-roles.md deleted file mode 100644 index 33fdf463228b109..000000000000000 --- a/rfcs/aria-roles.md +++ /dev/null @@ -1,110 +0,0 @@ -# MDN content project: ARIA roles reference docs - -This RFC proposes that we work on completing the [ARIA role reference docs](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles) -available on MDN. We did quite a bit of work on this in the past, including -having it as a major workstream at a past [Accessibility Hack on MDN event](https://hacks.mozilla.org/2018/10/hack-on-mdn-better-accessibility-for-mdn-web-docs/), -but we still never got around to completing the docs. - -## Problem statement - -ARIA roles are an important part of the [WAI-ARIA](https://w3c.github.io/aria/) -technology standard — they allow us to provide semantics where semantics are -lacking, for the benefit of AT and AT-users. Unfortunately many roles are a bit -obscure in their use, especially across different browser and screenreader -combinations, and a lot of information on this topic is spread far and wide -across the Web. It would be great to provide a deep and complete resource on -this in one place. - -## Priority assessment - -This table checks this project against the [OWD prioritization criteria](https://github.com/openwebdocs/project/blob/main/steering-committee/prioritization-criteria.md). - -- **Effort**: Medium/High: Each page (60) is fairly large and may require some - research. -- **Dependencies**: Need to find accessibility experts to help. -- **Community enablement**: Yes. Each page is a self-contained task. -- **Momentum**: Low/Medium. The tech itself is fairly stable, but a11y is - something we want to push. -- **Enabling learners**: Not really. The MDN Learn section contains ARIA basics - already. -- **Enabling professionals**: Yes. -- **Underrepresented topics / Ethical web**: Yes. We want to push forward the - importance of a11y and make it easier to action. -- **Operational necessities**: In a way, yes. Without a11y, certain groups - cannot use the web. -- **Addressing the needs of the web industry**: Accessibility not seen as a - major pain point in Web DNA, but is that just because people don't understand - it? - -## Proposed solutions - -We need to write those pages. - -## Task list - -- Write out list of which roles pages are not written yet, and which ones are - incomplete/need improvement. -- Make sure we agree on a template to base each page on — what does each page - need? -- Write an issue for each page, and try to enlist the help of a11y experts to - write recommendations for the use cases/potential examples for each role, - plus links to anything that would help people get started. -- Contact folks in the a11y community who might be willing to help write such - pages. Get them working on pages. -- Create a spreadsheet to track progress on each page. - -### Unwritten role pages - -Using [categorization of roles](https://www.w3.org/TR/wai-aria-1.1/#roles_categorization) -as an exhaustive list, the following roles lack a page: - -- command (abstract, should not be used in content) -- composite (abstract, should not be used in content) -- input (abstract, should not be used in content) -- landmark (abstract, should not be used in content) -- range (abstract, should not be used in content) -- roletype (abstract, should not be used in content) -- section (abstract, should not be used in content) -- sectionhead (abstract, should not be used in content) -- select (abstract, should not be used in content) -- structure (abstract, should not be used in content) -- widget (abstract, should not be used in content) -- window (abstract, should not be used in content) -- menuitem (widget role) -- menuitemcheckbox (widget role) -- menuitemradio (widget role) -- option (widget role) -- scrollbar (widget role) -- searchbox (widget role) -- separator (when focusable, widget role) -- spinbutton (widget role) -- treeitem (widget role) -- combobox (composite role) -- menu (composite role) -- menubar (composite role) -- tablist (composite role) -- tree (composite role) -- treegrid (composite role) -- columnheader (document structure role) -- definition (document structure role) -- directory (document structure role) -- feed (document structure role) -- math (document structure role) -- none (document structure role) -- note (document structure role) -- rowheader (document structure role) -- separator (when not focusable, document structure role) -- term (document structure role) -- tooltip (document structure role) -- marquee (live region role) - -Don't forget to update the link in -[MDN's list of ARIA roles](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques) -once these pages were written! - -### Related issues - -Some role pages have opened issues already. This is a list to keep track of -them, until the spreadsheet was created: - -- [ ] [Content suggestion: Aria tabpanel and tablist role #3924](https://github.com/mdn/content/issues/3924) diff --git a/rfcs/modernize-learn-js.md b/rfcs/modernize-learn-js.md deleted file mode 100644 index 8a8870fc755c2c7..000000000000000 --- a/rfcs/modernize-learn-js.md +++ /dev/null @@ -1,74 +0,0 @@ -# MDN content project: Modernizing the Learning Area JavaScript modules - -This RFC proposes that we work on modernizing the [Learning Area JavaScript modules](https://developer.mozilla.org/en-US/docs/Learn/JavaScript) -available on MDN. - -## Problem statement - -The JavaScript learning area modules are pretty good as they stand, and still -helpful to aspiring web developers. The main problem is that many of the -component articles were written before the time that MDN's JS policy was -changed (from "don't use ES6 features, they are too modern" to "use modern -features"). - -As a result, a number of articles are a bit out of date, or teach the old way -of doing something first, with the new way added in as a new section at the end. - -Examples: - -- In the [Handling text — strings in JavaScript](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/First_steps/Strings) - article, old-school string concatenation is introduced centrally, - whereas template literals are introduced at the end as a newer syntax that - you'll also come across. This should really be done the other way round. -- In the [arrays introduction](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/First_steps/Arrays), - the basics are explained just fine, but there is no coverage of modern array - methods that are very commonplace in JS these days, such as `map()` or `filter()`. -- In the [JS objects module](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects), - old-school constructors and prototypes are introduced first, and ES class - syntax is tacked on the end as an afterthought. This should be the other way - round. -- We did some work on making sure that `const`/`let` is used in appropriate - Places instead of `var`. We should check to see if there is any more work to - do here. -- We should include a guide early on about targeting browsers, where we could - cover things like considering which browsers/non-browser runtimes you need to - support, making it clear that we only support modern browsers in these guides, - and setting up tools like Babel.js if you want to support ancient engines. - -## Priority assessment - -This list checks this project against the [OWD prioritization criteria](https://github.com/openwebdocs/project/blob/main/steering-committee/prioritization-criteria.md). - -- **Effort**: Medium/High: There are over 40 JavaScript articles in the - learning area, and each one needs to be audited, a decision made about what we - should do with it, and then rewriting work done. Related examples also need - to be updated. -- **Dependencies**: Not much to mention here. -- **Community enablement**: Yes. Each page rewrite is a self-contained task, so - we could get community to help out here. -- **Momentum**: Medium. A lot of features we'd be writing about are pretty - stable, but the technology is very popular. -- **Enabling learners**: Yes!! -- **Enabling professionals**: Yes, somewhat. Even professional web developers - can often benefit greatly from an authoritative source of information show - the modern way to write JS. We should aim to keep this pretty up-to-date. -- **Underrepresented topics / Ethical web**: n/a -- **Operational necessities**: n/a -- **Addressing the needs of the web industry**: n/a - -## Proposed solutions - -Audit existing articles, work out how to update them, get them rewritten. - -## Task list - -- Agree on an overall strategy for the updates. For example, is there a - particular set of ECMAScript that we want to stick to documenting in this - resource? How new is too new? Do we gate it on what is supported in at least - two rendering engines, or some such thing? How do we deal with - backwards-compatibility? Show examples of how to support older browsers, or - just teach everyone how to use Babel.js to begin with? -- Audit each page. For each one, write a list of what needs to be done to get - that page updated in line with the above strategy. -- Find writers to help do this work. -- Divide the writing and reviewing work up between the available writers. diff --git a/rfcs/webview-information.md b/rfcs/webview-information.md deleted file mode 100644 index 02edb9caaedccc1..000000000000000 --- a/rfcs/webview-information.md +++ /dev/null @@ -1,60 +0,0 @@ -# MDN content project: WebView information on MDN - -This RFC proposes that we work on adding WebView documentation to MDN, to help -web developers figure out how to test and support WebView environments (i.e. iOS -and Android WebView-based "mega app" type environments). - -This would include: - -- What is a WebView environment? -- How frequently WebView environments are used and in what regions they are - used the most. -- How WebView environments differ from their browser counterparts. -- How to test a site in WebView environments. -- How to detect whether a site is running in a WebView environment at runtime. -- General overview of WebView API compatibility patterns, exceptions, and pain - points, e.g. how to handle feature detection false positives. - -## Problem statement - -WebView environments are used more than you might think (early data suggests -that up to 20% of Android web use is WebView), but there is very little -information available on how to effectively support them, and some thorny -problems to overcome, for example certain features that are supported in a -rendering engine but don't work because of environmental differences. - -## Priority assessment - -This table checks this project against the [OWD prioritization criteria](https://github.com/openwebdocs/project/blob/main/steering-committee/prioritization-criteria.md). - -- **Effort**: Low to medium. This is probably not a huge amount of content. -- **Dependencies**: Need to find experts in this area to help. -- **Community enablement**: Potentially, yes. Each page is a self-contained task. -- **Momentum**: Medium. WebView usage is on the rise; more people are becoming - aware of these issues. -- **Enabling learners**: Not really. -- **Enabling professionals**: Yes. -- **Underrepresented topics / Ethical web**: n/a. -- **Operational necessities**: n/a. -- **Addressing the needs of the web industry**: Yes. As mentioned before, this - kind of information is becoming more sought after. - -## Proposed solutions - -We need to write this content. - -## Task list - -- Write out summary of what content we want to produce, and organize it into a - set of pages. -- Write an issue for each page, and try to enlist the help of experts in this area to - write the content. -- Contact folks in the community who might be willing to help write such - pages. Get them working on pages. -- Create a spreadsheet to track progress on each page. - -## Useful links - -- [What is in a Web View? An Analysis of Progressive Web App Features When the Means - of Web Access is not a Web Browser](https://research.google/pubs/pub46739/) by - Thomas Steiner.