Tweak line wrappings in content-organization.md
Michael
parent
903aca3e21
commit
1ec7fe8e63
|
|
@ -17,8 +17,6 @@ You can register for Kubernetes Slack at https://slack.k8s.io/.
|
|||
For information on creating new content for the Kubernetes
|
||||
docs, follow the [style guide](/docs/contribute/style/style-guide).
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
|
@ -40,15 +38,19 @@ Kubernetes docs allow content for third-party projects only when:
|
|||
|
||||
### Third party content
|
||||
|
||||
Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and
|
||||
Kubernetes documentation includes applied examples of projects in the Kubernetes
|
||||
project—projects that live in the [kubernetes](https://github.com/kubernetes) and
|
||||
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
|
||||
|
||||
Links to active content in the Kubernetes project are always allowed.
|
||||
|
||||
Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
|
||||
[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/), and [logging](/docs/concepts/cluster-administration/logging/).
|
||||
[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins),
|
||||
[Ingress controllers](/docs/concepts/services-networking/ingress-controllers/),
|
||||
and [logging](/docs/concepts/cluster-administration/logging/).
|
||||
|
||||
Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function.
|
||||
Docs can link to third-party open source software (OSS) outside the Kubernetes
|
||||
project only if it's necessary for Kubernetes to function.
|
||||
|
||||
### Dual sourced content
|
||||
|
||||
|
|
@ -59,19 +61,14 @@ Dual-sourced content requires double the effort (or more!) to maintain
|
|||
and grows stale more quickly.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
If you're a maintainer for a Kubernetes project and need help hosting your own docs,
|
||||
ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/).
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
### More information
|
||||
|
||||
If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask!
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Read the [Style guide](/docs/contribute/style/style-guide).
|
||||
|
|
|
|||
|
|
@ -4,13 +4,10 @@ content_type: concept
|
|||
weight: 90
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
{{% note %}}
|
||||
|
|
@ -21,7 +18,9 @@ This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-m
|
|||
|
||||
### Page Order
|
||||
|
||||
The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first), and finally by the link title.
|
||||
The documentation side menu, the documentation page browser etc. are listed using
|
||||
Hugo's default sort order, which sorts by weight (from 1), date (newest first),
|
||||
and finally by the link title.
|
||||
|
||||
Given that, if you want to move a page or a section up, set a weight in the page's front matter:
|
||||
|
||||
|
|
@ -30,24 +29,25 @@ title: My Page
|
|||
weight: 10
|
||||
```
|
||||
|
||||
|
||||
{{% note %}}
|
||||
For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval, say 10, 20, 30... This allows you to insert pages where you want later.
|
||||
Additionally, each weight within the same directory (section) should not be overlapped with the other weights. This makes sure that content is always organized correctly, especially in localized content.
|
||||
For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval,
|
||||
say 10, 20, 30... This allows you to insert pages where you want later.
|
||||
Additionally, each weight within the same directory (section) should not be
|
||||
overlapped with the other weights. This makes sure that content is always
|
||||
organized correctly, especially in localized content.
|
||||
{{% /note %}}
|
||||
|
||||
|
||||
### Documentation Main Menu
|
||||
|
||||
The `Documentation` main menu is built from the sections below `docs/` with the `main_menu` flag set in front matter of the `_index.md` section content file:
|
||||
The `Documentation` main menu is built from the sections below `docs/` with
|
||||
the `main_menu` flag set in front matter of the `_index.md` section content file:
|
||||
|
||||
```yaml
|
||||
main_menu: true
|
||||
```
|
||||
|
||||
|
||||
Note that the link title is fetched from the page's `linkTitle`, so if you want it to be something different than the title, change it in the content file:
|
||||
|
||||
Note that the link title is fetched from the page's `linkTitle`, so if you want
|
||||
it to be something different than the title, change it in the content file:
|
||||
|
||||
```yaml
|
||||
main_menu: true
|
||||
|
|
@ -55,9 +55,10 @@ title: Page Title
|
|||
linkTitle: Title used in links
|
||||
```
|
||||
|
||||
|
||||
{{% note %}}
|
||||
The above needs to be done per language. If you don't see your section in the menu, it is probably because it is not identified as a section by Hugo. Create a `_index.md` content file in the section folder.
|
||||
The above needs to be done per language. If you don't see your section in the menu,
|
||||
it is probably because it is not identified as a section by Hugo. Create a
|
||||
`_index.md` content file in the section folder.
|
||||
{{% /note %}}
|
||||
|
||||
### Documentation Side Menu
|
||||
|
|
@ -72,11 +73,13 @@ If you don't want to list a section or page, set the `toc_hide` flag to `true` i
|
|||
toc_hide: true
|
||||
```
|
||||
|
||||
When you navigate to a section that has content, the specific section or page (e.g. `_index.md`) is shown. Else, the first page inside that section is shown.
|
||||
When you navigate to a section that has content, the specific section or page
|
||||
(e.g. `_index.md`) is shown. Else, the first page inside that section is shown.
|
||||
|
||||
### Documentation Browser
|
||||
|
||||
The page browser on the documentation home page is built using all the sections and pages that are directly below the `docs section`.
|
||||
The page browser on the documentation home page is built using all the sections
|
||||
and pages that are directly below the `docs section`.
|
||||
|
||||
If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter:
|
||||
|
||||
|
|
@ -86,14 +89,18 @@ toc_hide: true
|
|||
|
||||
### The Main Menu
|
||||
|
||||
The site links in the top-right menu -- and also in the footer -- are built by page-lookups. This is to make sure that the page actually exists. So, if the `case-studies` section does not exist in a site (language), it will not be linked to.
|
||||
|
||||
The site links in the top-right menu -- and also in the footer -- are built by
|
||||
page-lookups. This is to make sure that the page actually exists. So, if the
|
||||
`case-studies` section does not exist in a site (language), it will not be linked to.
|
||||
|
||||
## Page Bundles
|
||||
|
||||
In addition to standalone content pages (Markdown files), Hugo supports [Page Bundles](https://gohugo.io/content-management/page-bundles/).
|
||||
In addition to standalone content pages (Markdown files), Hugo supports
|
||||
[Page Bundles](https://gohugo.io/content-management/page-bundles/).
|
||||
|
||||
One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/). It is considered a `leaf bundle`. Everything below the directory, including the `index.md`, will be part of the bundle. This also includes page-relative links, images that can be processed etc.:
|
||||
One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/).
|
||||
It is considered a `leaf bundle`. Everything below the directory, including the `index.md`,
|
||||
will be part of the bundle. This also includes page-relative links, images that can be processed etc.:
|
||||
|
||||
```bash
|
||||
en/docs/home/contribute/includes
|
||||
|
|
@ -103,7 +110,8 @@ en/docs/home/contribute/includes
|
|||
└── podtemplate.json
|
||||
```
|
||||
|
||||
Another widely used example is the `includes` bundle. It sets `headless: true` in front matter, which means that it does not get its own URL. It is only used in other pages.
|
||||
Another widely used example is the `includes` bundle. It sets `headless: true` in
|
||||
front matter, which means that it does not get its own URL. It is only used in other pages.
|
||||
|
||||
```bash
|
||||
en/includes
|
||||
|
|
@ -118,22 +126,22 @@ en/includes
|
|||
|
||||
Some important notes to the files in the bundles:
|
||||
|
||||
* For translated bundles, any missing non-content files will be inherited from languages above. This avoids duplication.
|
||||
* All the files in a bundle are what Hugo calls `Resources` and you can provide metadata per language, such as parameters and title, even if it does not supports front matter (YAML files etc.). See [Page Resources Metadata](https://gohugo.io/content-management/page-resources/#page-resources-metadata).
|
||||
* The value you get from `.RelPermalink` of a `Resource` is page-relative. See [Permalinks](https://gohugo.io/content-management/urls/#permalinks).
|
||||
|
||||
* For translated bundles, any missing non-content files will be inherited from
|
||||
languages above. This avoids duplication.
|
||||
* All the files in a bundle are what Hugo calls `Resources` and you can provide
|
||||
metadata per language, such as parameters and title, even if it does not supports
|
||||
front matter (YAML files etc.).
|
||||
See [Page Resources Metadata](https://gohugo.io/content-management/page-resources/#page-resources-metadata).
|
||||
* The value you get from `.RelPermalink` of a `Resource` is page-relative.
|
||||
See [Permalinks](https://gohugo.io/content-management/urls/#permalinks).
|
||||
|
||||
## Styles
|
||||
|
||||
The [SASS](https://sass-lang.com/) source of the stylesheets for this site is stored in `assets/sass` and is automatically built by Hugo.
|
||||
|
||||
|
||||
The [SASS](https://sass-lang.com/) source of the stylesheets for this site is
|
||||
stored in `assets/sass` and is automatically built by Hugo.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn about [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)
|
||||
* Learn about the [Style guide](/docs/contribute/style/style-guide)
|
||||
* Learn about the [Content guide](/docs/contribute/style/content-guide)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ For additional information on creating new content for the Kubernetes
|
|||
documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/).
|
||||
|
||||
Changes to the style guide are made by SIG Docs as a group. To propose a change
|
||||
or addition, [add it to the agenda](https://bit.ly/sig-docs-agenda) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
discussion.
|
||||
or addition, [add it to the agenda](https://bit.ly/sig-docs-agenda) for an upcoming
|
||||
SIG Docs meeting, and attend the meeting to participate in the discussion.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -42,11 +42,17 @@ The English-language documentation uses U.S. English spelling and grammar.
|
|||
|
||||
### Use upper camel case for API objects
|
||||
|
||||
When you refer specifically to interacting with an API object, use [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as Pascal case. You may see different capitalization, such as "configMap", in the [API Reference](/docs/reference/kubernetes-api/). When writing general documentation, it's better to use upper camel case, calling it "ConfigMap" instead.
|
||||
When you refer specifically to interacting with an API object, use
|
||||
[UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as
|
||||
Pascal case. You may see different capitalization, such as "configMap",
|
||||
in the [API Reference](/docs/reference/kubernetes-api/). When writing
|
||||
general documentation, it's better to use upper camel case, calling it "ConfigMap" instead.
|
||||
|
||||
When you are generally discussing an API object, use [sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
|
||||
When you are generally discussing an API object, use
|
||||
[sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
|
||||
|
||||
The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#code-style-inline-code).
|
||||
The following examples focus on capitalization. For more information about formatting
|
||||
API object names, review the related guidance on [Code Style](#code-style-inline-code).
|
||||
|
||||
{{< table caption = "Do and Don't - Use Pascal case for API objects" >}}
|
||||
Do | Don't
|
||||
|
|
@ -130,7 +136,9 @@ Remove trailing spaces in the code. | Add trailing spaces in the code, where the
|
|||
{{< /table >}}
|
||||
|
||||
{{< note >}}
|
||||
The website supports syntax highlighting for code samples, but specifying a language is optional. Syntax highlighting in the code block should conform to the [contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum)
|
||||
The website supports syntax highlighting for code samples, but specifying a language
|
||||
is optional. Syntax highlighting in the code block should conform to the
|
||||
[contrast guidelines.](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum)
|
||||
{{< /note >}}
|
||||
|
||||
### Use code style for object field names and namespaces
|
||||
|
|
@ -189,7 +197,10 @@ This section talks about how we reference API resources in the documentation.
|
|||
|
||||
### Clarification about "resource"
|
||||
|
||||
Kubernetes uses the word "resource" to refer to API resources, such as `pod`, `deployment`, and so on. We also use "resource" to talk about CPU and memory requests and limits. Always refer to API resources as "API resources" to avoid confusion with CPU and memory resources.
|
||||
Kubernetes uses the word "resource" to refer to API resources, such as `pod`,
|
||||
`deployment`, and so on. We also use "resource" to talk about CPU and memory
|
||||
requests and limits. Always refer to API resources as "API resources" to avoid
|
||||
confusion with CPU and memory resources.
|
||||
|
||||
### When to use Kubernetes API terminologies
|
||||
|
||||
|
|
@ -197,21 +208,27 @@ The different Kubernetes API terminologies are:
|
|||
|
||||
- Resource type: the name used in the API URL (such as `pods`, `namespaces`)
|
||||
- Resource: a single instance of a resource type (such as `pod`, `secret`)
|
||||
- Object: a resource that serves as a "record of intent". An object is a desired state for a specific part of your cluster, which the Kubernetes control plane tries to maintain.
|
||||
- Object: a resource that serves as a "record of intent". An object is a desired
|
||||
state for a specific part of your cluster, which the Kubernetes control plane tries to maintain.
|
||||
|
||||
Always use "resource" or "object" when referring to an API resource in docs. For example, use "a `Secret` object" over just "a `Secret`".
|
||||
Always use "resource" or "object" when referring to an API resource in docs.
|
||||
For example, use "a `Secret` object" over just "a `Secret`".
|
||||
|
||||
### API resource names
|
||||
|
||||
Always format API resource names using [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as PascalCase, and code formatting.
|
||||
Always format API resource names using [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case),
|
||||
also known as PascalCase, and code formatting.
|
||||
|
||||
For inline code in an HTML document, use the `<code>` tag. In a Markdown document, use the backtick (`` ` ``).
|
||||
|
||||
Don't split an API object name into separate words. For example, use `PodTemplateList`, not Pod Template List.
|
||||
|
||||
For more information about PascalCase and code formatting, please review the related guidance on [Use upper camel case for API objects](/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects) and [Use code style for inline code, commands, and API objects](/docs/contribute/style/style-guide/#code-style-inline-code).
|
||||
For more information about PascalCase and code formatting, please review the related guidance on
|
||||
[Use upper camel case for API objects](/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects)
|
||||
and [Use code style for inline code, commands, and API objects](/docs/contribute/style/style-guide/#code-style-inline-code).
|
||||
|
||||
For more information about Kubernetes API terminologies, please review the related guidance on [Kubernetes API terminology](/docs/reference/using-api/api-concepts/#standard-api-terminology).
|
||||
For more information about Kubernetes API terminologies, please review the related
|
||||
guidance on [Kubernetes API terminology](/docs/reference/using-api/api-concepts/#standard-api-terminology).
|
||||
|
||||
## Code snippet formatting
|
||||
|
||||
|
|
@ -240,17 +257,23 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
|||
|
||||
### Versioning Kubernetes examples
|
||||
|
||||
Code examples and configuration examples that include version information should be consistent with the accompanying text.
|
||||
Code examples and configuration examples that include version information should
|
||||
be consistent with the accompanying text.
|
||||
|
||||
If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-content-types/#task) or the [Tutorial template](/docs/contribute/style/page-content-types/#tutorial). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
|
||||
If the information is version specific, the Kubernetes version needs to be defined
|
||||
in the `prerequisites` section of the [Task template](/docs/contribute/style/page-content-types/#task)
|
||||
or the [Tutorial template](/docs/contribute/style/page-content-types/#tutorial).
|
||||
Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
|
||||
|
||||
To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page.
|
||||
To specify the Kubernetes version for a task or tutorial page, include
|
||||
`min-kubernetes-server-version` in the front matter of the page.
|
||||
|
||||
If the example YAML is in a standalone file, find and review the topics that include it as a reference.
|
||||
Verify that any topics using the standalone YAML have the appropriate version information defined.
|
||||
If a stand-alone YAML file is not referenced from any topics, consider deleting it instead of updating it.
|
||||
|
||||
For example, if you are writing a tutorial that is relevant to Kubernetes version 1.8, the front-matter of your markdown file should look something like:
|
||||
For example, if you are writing a tutorial that is relevant to Kubernetes version 1.8,
|
||||
the front-matter of your markdown file should look something like:
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -283,7 +306,10 @@ On-premises | On-premises or On-prem rather than On-premise or other variations.
|
|||
|
||||
## Shortcodes
|
||||
|
||||
Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** `{{</* note */>}}`, **Caution** `{{</* caution */>}}`, and **Warning** `{{</* warning */>}}`.
|
||||
Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create
|
||||
different rhetorical appeal levels. Our documentation supports three different
|
||||
shortcodes in this category: **Note** `{{</* note */>}}`,
|
||||
**Caution** `{{</* caution */>}}`, and **Warning** `{{</* warning */>}}`.
|
||||
|
||||
1. Surround the text with an opening and closing shortcode.
|
||||
|
||||
|
|
@ -412,7 +438,8 @@ The output is:
|
|||
|
||||
### Include Statements
|
||||
|
||||
Shortcodes inside include statements will break the build. You must insert them in the parent document, before and after you call the include. For example:
|
||||
Shortcodes inside include statements will break the build. You must insert them
|
||||
in the parent document, before and after you call the include. For example:
|
||||
|
||||
```
|
||||
{{</* note */>}}
|
||||
|
|
@ -424,11 +451,19 @@ Shortcodes inside include statements will break the build. You must insert them
|
|||
|
||||
### Line breaks
|
||||
|
||||
Use a single newline to separate block-level content like headings, lists, images, code blocks, and others. The exception is second-level headings, where it should be two newlines. Second-level headings follow the first-level (or the title) without any preceding paragraphs or texts. A two line spacing helps visualize the overall structure of content in a code editor better.
|
||||
Use a single newline to separate block-level content like headings, lists, images,
|
||||
code blocks, and others. The exception is second-level headings, where it should
|
||||
be two newlines. Second-level headings follow the first-level (or the title) without
|
||||
any preceding paragraphs or texts. A two line spacing helps visualize the overall
|
||||
structure of content in a code editor better.
|
||||
|
||||
### Headings and titles {#headings}
|
||||
|
||||
People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.
|
||||
People accessing this documentation may use a screen reader or other assistive technology (AT).
|
||||
[Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices,
|
||||
they output items on a page one at a time. If there is a lot of content on a page, you can
|
||||
use headings to give the page an internal structure. A good page structure helps all readers
|
||||
to easily navigate the page or filter topics of interest.
|
||||
|
||||
{{< table caption = "Do and Don't - Headings" >}}
|
||||
Do | Don't
|
||||
|
|
@ -460,12 +495,20 @@ Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](
|
|||
|
||||
### Lists
|
||||
|
||||
Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
|
||||
Website navigation links can also be marked up as list items; after all they are nothing but a group of related links.
|
||||
Group items in a list that are related to each other and need to appear in a specific
|
||||
order or to indicate a correlation between multiple items. When a screen reader comes
|
||||
across a list—whether it is an ordered or unordered list—it will be announced to the
|
||||
user that there is a group of list items. The user can then use the arrow keys to move
|
||||
up and down between the various items in the list. Website navigation links can also be
|
||||
marked up as list items; after all they are nothing but a group of related links.
|
||||
|
||||
- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.
|
||||
- End each item in a list with a period if one or more items in the list are complete
|
||||
sentences. For the sake of consistency, normally either all items or none should be complete sentences.
|
||||
|
||||
{{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}}
|
||||
{{< note >}}
|
||||
Ordered lists that are part of an incomplete introductory sentence can be in lowercase
|
||||
and punctuated as if each item was a part of the introductory sentence.
|
||||
{{< /note >}}
|
||||
|
||||
- Use the number one (`1.`) for ordered lists.
|
||||
|
||||
|
|
@ -475,11 +518,15 @@ Website navigation links can also be marked up as list items; after all they are
|
|||
|
||||
- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
|
||||
|
||||
- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.
|
||||
- List items may consist of multiple paragraphs. Each subsequent paragraph in a list
|
||||
item must be indented by either four spaces or one tab.
|
||||
|
||||
### Tables
|
||||
|
||||
The semantic purpose of a data table is to present tabular data. Sighted users can quickly scan the table but a screen reader goes through line by line. A table caption is used to create a descriptive title for a data table. Assistive technologies (AT) use the HTML table caption element to identify the table contents to the user within the page structure.
|
||||
The semantic purpose of a data table is to present tabular data. Sighted users can
|
||||
quickly scan the table but a screen reader goes through line by line. A table caption
|
||||
is used to create a descriptive title for a data table. Assistive technologies (AT)
|
||||
use the HTML table caption element to identify the table contents to the user within the page structure.
|
||||
|
||||
- Add table captions using [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions) for tables.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue