---
tags: 學習筆記, Website, HTML, CSS, JS, Accessibility
---
# 無障礙網站開發筆記
###### tags: `Accessibility`
## Overview
Nowadays websites that belong to any offical or non-offical organization, are required to adopt new **accessibility** standard, due to new policy of **Ministry of Digital Affairs**.
This note is main to learn **common accessibility** and help related issues and difficulties occurred during website development.
Hop it can help you, hopefully.
## Handling common accessibility problems
### HTML
###### tags: `HTML`
#### Semantic structure
1. Content structure of headings and paragraphs.
```htmlembedded=
<h1>My heading</h1>
<p>This is the first section of my document.</p>
<h2>My subheading</h2>
<p>This is the first subsection of my document.</p>
```
2. Logical sense source order.
:::info
:fire: During test, turning off a site's CSS can see how understandable it is without it.
:::
#### Native keyboard accessibility
Using **Tab** (next), **Shift+Tab** (previous) to move between focusable elements. Or choosing options in ``<select>`` tag by up/down arrow key.
>取自 [Mdn Web Docs](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility)
>>In Firefox, you can also enable an overlay that shows the page tabbing order. For more information see: [Accessibility Inspector > Show web page tabbing order](https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/index.html#show-web-page-tabbing-order).
#### Building in keyboard accessibility
1. Create custom controls using ``<button>`` elements
**(which we can tab to by default!)**
2. Create keyboard shortcuts via JavaScriptSS.
3. Use some interesting tactics to fake button behavior.
For example creating button by ``<div>`` tag(**not recommanded**) and make it **focusable** by giving attribute ``tabindex="0"`` and activate them via the **Enter/Return key** by javaScript.more detail in [WebAIM's tabindex article](https://webaim.org/techniques/keyboard/tabindex)
```javascript=
document.onkeydown = (e) => {
if (e.keyCode === 13) {
// The Enter/Return key
document.activeElement.onclick(e);
}
};
```
#### Text alternatives
For person who have **visual and hearing impairment**, ``<alt=""{text}>`` is an aleternative to contain a description of the **image** that successfully conveys its meaning and content, and also can be picked up by a **screen reader** and read out to the user.
#### Element relationships and context
There are certain features and best practices in HTML designed to provide context and relationships between elements where none otherwise exists. The three most common examples are links, form labels, and data tables.
1. Links
Reasonable link text for link in or out of context. **Avoid** to use context such as "click me", "click here",etc.
2. Form labels
Access``<label>``is one of the central features that allows us to make forms accessible. By ``for="{id}"`` attribute and element ``id`` value,that create a quick access to it's bound partner, such as ``<input>``, ``<select>``, ``<textarea>``, etc.
```htmlembedded=
<form>
<label for="{value}">This is a lable</label>
<input id="{value}" type="text">
</form>
```
3. Data tables
A basic data table can be written with very simple markup, but for screen reader users there is **no way to associate rows or columns together as groupings of data**. Within some accessibilities, such as ``<caption>``, ``thead``, ``tbody`` and ``scoped="{col/row}"`` attribute, can improve the issue above.
```htmlembedded=
<!-- Original -->
<table>
<tr>
<td>Name</td>
<td>Age</td>
<td>Gender</td>
</tr>
<tr>
<td>Gabriel</td>
<td>13</td>
<td>Male</td>
</tr>
</table>
```
```htmlembedded=
<!-- Improved -->
<table>
<caption>Table captions</caption>
<thead>
<tr>
<th scope="col">Column title one</th>
<th scope="col">Column title two</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row"></th>
<td></td>
</tr>
<tr>
<th scope="row"></th>
<td></td>
</tr>
</tbody>
</table>
```
### CSS
###### tags: `css`
CSS provides much fewer fundamental accessibility features compare to HTML, but damage to accessibility still can be made due to incorrectly use.
#### Font-size
Use css ``font-size:`` attribute insted of ``<h1>~<h6>`` tags. Or HTML semantic structure would be **messed**, when you trying to create a different visual effect.
#### Interactive element
To provide users visual clues as their visiting. Be sure of Interactive element like **buttons** and **links** are appropriate set, when ``:focus``, ``hover``, ``active`` states occurred.
>取自 [Mdn Web Docs](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility)
>>Make sure your source order makes sense without CSS; you can always use CSS to style the page any way you want afterward.
#### Color and color contrast
Make sure your text(foreground) and background color contrast well, or visual impairments like **color blindness** won't be able to read your content.
And the other alternative way is that
>取自 [Mdn Web Docs](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility)
>>A high contrast ratio will also allow anyone using a smartphone or tablet with a glossy screen to better read pages when in a bright environment, such as sunlight.
:::info
:fire: Color contrast tools:
* [WCAG Color contrast checker](https://chrome.google.com/webstore/detail/wcag-color-contrast-check/plnahcmalebffmaghcpcmpaciebdhgdf/related) (Chrome plugin)
* [WebAIM Color contrast checker](https://webaim.org/resources/contrastchecker/) (Website)
:::
#### Hiding cotent
By CSS attributes like ``display: none;`` and ``visible:hidden;``, content will be **hiden** from screen reader. To avoid this situation, ``position: absolute``(absolutely positioning content **off-screen**) is much proper way to achieve this visual effect.
### JavaScript
As same as CSS, within bad use of JavaScript also could disturb user accessibility.
>取自 [Mdn Web Docs](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility)
>>In the area of semantic HTML — you should always use **appropriate semantic HTML** to implement functionality wherever it is available.
#### Simple functionality
JavaScript should only be used **to enhance functionality**, instead of building it entirely.
* Providing client-side form validation
Inform users to problem with their form , without waiting for server response.
:::info
:fire: More complex JavaScript implementations can create issues with accessibility.
:::
#### Complex functionality
1. Dynamic content
Generally dynamic content can be **missed by screen reader**, especially when update was unexpectedly. Such as ``select``'s ``option``s, when content was updated through **XMLHttpRequest**, **Fetch** or any posible way, the situation could occurr.
:::info
:fire: [StackOverflow - Accessible Ajax Region](https://stackoverflow.com/questions/38256399/how-to-create-screen-reader-accessible-ajax-regions-and-dom-insert-remove-update) :
* Framework likes **Vue** and **Anuglar** suppoert accessibility, by providing attribues, such as ``aria-live="polite"`` and ``aria-atomic='true'`` to alert user the update occurred.
:::
2. Form control
* Non-native form
**Non-native complicated form** contains lots of nested ``<div>``, for browser, it is **hard to recoginize** by default. if possible, you better make them keyboard accessible.
* Third-party framwork
if some third-party framworks are used in your apps, please carefully review the options available to see how accessible they are before using them.
:::info
:fire: Bootstrap looks to be fairly good for accessibility.
:::
## Accessibility tools
## Accessibility testing checklist
###### tags: `Checklsit`,`Strandard`
- [ ] Make sure your HTML is as semantically correct as possible. Validating it is a good start, as is using an Auditing tool.
- [ ] Check that your content makes sense when the CSS is turned off.
- [ ] Make sure your functionality is keyboard accessible. Test using Tab, Return/Enter, etc.
- [ ] Make sure your non-text content has text alternatives. An Auditing tool is good for catching such problems.
- [ ] Make sure your site's color contrast is acceptable, using a suitable checking tool.
- [ ] Make sure hidden content is visible by screen readers.
- [ ] Make sure that functionality is usable without JavaScript wherever possible.
- [ ] Use ARIA to improve accessibility where appropriate.
- [ ] Run your site through an Auditing tool.
- [ ] Test it with a screen reader.
- [ ] Include an accessibility policy/statement somewhere findable on your site to say what you did.
>取自 [Mdn Web Docs](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility)
>>The following list provides a checklist for you to follow to make sure you've carried out the recommended accessibility testing for your project.
## 參考文獻
### Mdn Web Doc
- [x] [Handling common accessibility problems](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#common_accessibility_issues)
- [ ] [A good basis for accessibility](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#html_and_accessibility)
- [ ] [Desktop with mouse and keyboard](https://developer.mozilla.org/en-US/docs/Games/Techniques/Control_mechanisms/Desktop_with_mouse_and_keyboard)
- [ ] [WAI-ARIA basic](https://developer.mozilla.org/zh-TW/docs/Learn/Accessibility/WAI-ARIA_basics)
### WebAIM
- [ ] [Invisible Content Just for Screen Reader Users](https://webaim.org/techniques/css/invisiblecontent/)
- [ ] [Accessible JavaScript](https://webaim.org/techniques/javascript/)
### IT幫忙
- [ ] [一切都明朗了起來,無障礙網頁設計自我檢測工具](https://ithelp.ithome.com.tw/articles/10290282?sc=rss.iron)