If you run into any problems with the website or have specific questions, please use the `Issues` section of our GitHub repository [here](https://github.com/mcrosson/accessible.tips/issues).
We politely ask you review the open issues for exiting items that overlap. Please comment on an existing issue that is relevant prior to creating a new issue.
If there is not an existing issue for your need, please create a new issue. We politely ask you provide us as much detail as possible so we can hopefully respond without having to play a game of 20 questions.
We welcome updates to the contents of this website. Please use the `Issues` section [here](https://github.com/mcrosson/accessible.tips/issues) to submit any change requests for the site.
- simple edits with info on what changes to make (ie. spelling and grammer mistakes, bad sentence structure)
- full markdown files that are updates to existing pages
- asking for a tag to be added to a page
- asking to adjust categorization of a page or multiple pages
- various forms of the above
- pull requests (see below for an important note)
- more
If you'd like to submit full markdown files or larger edits, please review the contents of this page prior to submission. We've outlined some details on how we manage the content of this site below and ask our contributors follow these guidelines when submitting markdown changes.
If you'd like to submit an anecdote to the site anonymously, please get in touch via a burner account. We can work with you to get your anecdote published on the site via a ghost writer.
If you've used GitHub and git in the past, we will accept `Pull Requests` for updates. However, we will *not* describe the process here as it is an avanced topic we are not supporting directly. Consider `Pull Requests` a convenience that could go away in the future due to their inherent complexity.
{{<back_to_top>}}
### And More
{{<back_to_top>}}
Any other requests we ask be submitted as GitHub `Issues` [here](https://github.com/mcrosson/accessible.tips/issues).
{{<end_section>}}
## File and Folder Organization
{{<back_to_top>}}
Files and folders are setup with the following overall layout.
The `tips` directory contains the main knowledge base data. Each file represents a different page on the site and they are named using the format `[category]-[title].md` with `[category]` being the category set in the page metadata and `[title]` being the title set in the page metadata.
This allows us to easily cross reference information within a category (see [here]({{< ref "#cross-references" >}}) for how to cross reference pages) and keep the topic file names from colliding if there is any overlap between categories.
This rigid, tree'd structure is imposed by Hugo and we have adapted our file and folder organization to work with Hugo instead of against it.
This is also why we can have *only one* primary category for content currently.
We will also use `Page Bundles` ([Hugo docs](https://gohugo.io/content-management/page-bundles/)) for content that includes non-textual content or download links. `Page Bundles` are just folders with an `index.md` file and related assets. The `index.md` file is the main content and any files stored next to `index.md` can be easily referenced directly from `index.md`. This is particularly helpful for managing image assets and keeping them organized.
{{<back_to_top>}}
### Posts Directory
{{<back_to_top>}}
In this layout the `posts` directory contains all of the blog posts with dated file names using the given pattern. It's a pretty standard and simple folder organization scheme.
We will also use `Page Bundles` ([Hugo docs](https://gohugo.io/content-management/page-bundles/)) for content that includes non-textual content or download links. `Page Bundles` are just folders with an `index.md` file and related assets. The `index.md` file is the main content and any files stored next to `index.md` can be easily referenced directly from `index.md`. This is particularly helpful for managing image assets and keeping them organized.
{{<back_to_top>}}
### FAQ Directory
{{<back_to_top>}}
In this layout the `faq` directory contains all of the FAQ pages with file names matching the page title. It's a pretty standard and simple folder organization scheme.
We will also use `Page Bundles` ([Hugo docs](https://gohugo.io/content-management/page-bundles/)) for content that includes non-textual content or download links. `Page Bundles` are just folders with an `index.md` file and related assets. The `index.md` file is the main content and any files stored next to `index.md` can be easily referenced directly from `index.md`. This is particularly helpful for managing image assets and keeping them organized.
In this layout the `anecdotes` directory contains all of the Anecdote pages with `[author]` being the name of the first author, `[title]` being the title of the page and `[nnnn]` being a left padded 4 digit number that counts up from 1. This numbered serial allows us to avoid file name collisions while keeping the file layout a bit easier to manage.
We will also use `Page Bundles` ([Hugo docs](https://gohugo.io/content-management/page-bundles/)) for content that includes non-textual content or download links. `Page Bundles` are just folders with an `index.md` file and related assets. The `index.md` file is the main content and any files stored next to `index.md` can be easily referenced directly from `index.md`. This is particularly helpful for managing image assets and keeping them organized.
Fell free set your preferred name as the author, we like to attribute our authors. If you prefer to remain anonymous, please set authorship to `Anonymous`.
Please note: Authorship metadata will be publicly visible.
When editing an exiting post, we require you update the `lastMod` date in the front matter of all content pages. The date you use here should match the date used on the `Changelog` entry. See [Changelog Entries]({{< ref "#changelog-entries" >}}) for more info on `Changelog` dates.
We have tried to keep categories to a small, very high level set and we would like to keep this list focused and small presently.
That said: everyone conceptualizes references between information differently and we are open to working with users and authors to come up with a general list over time for the site.
We'd also like to point out the information contained on the site assumes just **one** category per content page. This is due to how `hugo` (our underlying technology for creating this site) organizes information as a set of folders. Due to this limitation we ask that contributors ensure that content has either `blog` or `tips` category set and only *one* other *primary* category.
If you'd like to get a new category added, please create a new issue [here](https://github.com/mcrosson/accessible.tips/issues/new) with the category, a brief description and any existing content page(s) you feel should be included in the category.
Please note: the submitted content page(s) do *not* have to be exhaustive or all inclusive.
We have tried to keep tags to a well curated list that help tie many different `Tips` togther. We have also tried to ensure tags are relevant to the category specified on each `Tip`.
Given how many words have large numbers of synonyms (alternatives), we have tried to stick to single tags for single concepts.
Please review the main tag list [here](/tags) (warning: this list can be large and take awhile to load) prior to creating a new tag. If one is missing, please add it.
Long term we hope to build a tag glossary to enhance discovery, search and synonym management. If/when this glossary is created, we will update our guidelines related to tagging.
If you are working on a tip that conflicts with any access needs, the tip *must* be tagged as conflicting with the form `conflicting-need-[specific_need]` where `specific_need` is a need such as `low-vision`.
You **must** only apply the `anecdote` tag and category to anecdote pages. These pages are personal accounts of living with disability and can be very triggering for readers.
We have setup the site to include a warning at the top of all anecdote pages and it *requires* the `anecdote` category be applied to these pages.
Submissions not tagging or categorizing anecdotes properly will *not* be approved for inclusion on this site.
For the `FAQ` section of the site we ask that you *only tag* entries with the `faq` tag. This allows the FAQ pages to be related to each other but still remain independent of the main site content. Adding additional tags will tie the FAQ pages into other content which is exactly what we want to avoid.
For the `News` section of the site we ask that you do **NOT** tag entries. The news pages are meant to be minimal and kept independent of the main site information. Adding a tag will tie the news pages into other content which is exactly what we want to avoid.
{{<end_section>}}
## Changelog Entries
{{<back_to_top>}}
This site uses GitHub for tracking the changes to the content used to generate the site. Please consider GitHub the source of truth for the data contained on this website.
However, that does *not* do our readers any good and we require all content pages have a `changelog` section in the front matter of each page. We require at least an entry for `Initial creation` as well.
If submitting content or copy edits, please note the following
- Each 2nd level heading should have the <code>{{< back_to_top >}}</code> short code on the line following the heading
- Each 3rd or higher level heading should have the <code>{{< end_section >}}</code> or <code>{{< back_to_top >}}</code> shortcode present at the end of the section. Use your best judgement on which of these two shortcodes to use
- If there are any sections beyond `Changelog`, the table of contents must be enabled
- When naming files, categories, tags and similar: use dashes ( `-` ) for separating words. Changes using Snakes ( `_` ) or `CamelCase` will **not** be approved for inclusion
<code>[Link Text]]({{< ref "[category]-[file]" >}})</code> where `[category]` is the category you defined and `[file]` is the markdown file name with the content you would like to reference.
When adding images to a page the page must be setup as a `Page Bundle` and the images stored in the page's bundle.
We have setup a short code that we ask authors to use for adding images. This shortcode will handle ensuring the appropriate `alt-text` is added to the image.
You can use the shortcode using the following pattern:
Where `[filename]` is the filename, including extension, of the image file. `[alt-text]` is the `img` tag's `alt-text` attribute value. `[visible-caption]` is the text that is shown just underneath each image as a caption.
Please note: we *require* contributors include `alt-text` on all images if not using the `figure` short code.
