KAMİS
A Level Principles
Non-Text Content
Principle
Textual alternatives must be provided for the content used on the website.
Description
Providing textual alternatives for the content presented on websites is crucial for enabling disabled users to use the website smoothly. It is necessary for accessibility that the presented content can have its text size increased when needed, be converted to Braille (a method of writing and reading for visually impaired individuals), transformed into symbols, listened to audibly, and have textual alternatives offered. However, textual alternatives may not be provided for visual elements used in website design or images used for Captcha applications that are unrelated to the content.
References
- WCAG 2.0 - Level A / 1.1.1
Example
In the example site, a description has been added for a news image. Using descriptions for all images ensures that images can be read by screen readers. The image descriptions should be relevant to the image they are used for.
Audio-Only and Video-Only Content
Principle
Alternatives for audio and video elements must be available.
Description
For pre-recorded audio and video elements, it is necessary to provide a textual alternative for the entire content or a summary of it. For example, to enable visually impaired users to fully benefit from the content of a video element, a text format that they can read or listen to through screen reader programs must be provided.
References
- WCAG 2.0 - Level A / 1.2.1
Example
In the example site, there is a transcript available for the video used. Users who wish can access the video content through the transcript.
Subtitles
Principle
Subtitle option should be included for video and audio elements.
Description
Subtitle are expected to be provided for audio or video content on websites. When creating captions, any surrounding sounds (e.g., audience laughter, applause, etc.) and cues should also be shared with users if applicable. If there is a text that describes the entire video content, subtitle usage may not be necessary. For audio content, especially in time-sensitive contexts like live broadcasts, providing sign language interpretation for users with hearing impairments is also preferred.
References
- WCAG 2.0 - Level A / 1.2.2
Example
In the example site, there are subtitles available for the video used. Users with hearing difficulties can access the video content through captions.
Audio Description or Media Alternatives
Principle
The provided audio descriptions and textual alternatives for audio and video elements must be descriptive.
Description
It may not be possible for disabled users to grasp audio or video elements presented on websites by listening alone. Therefore, the audio descriptions or textual alternatives provided for audio or video elements should inform users about both the content and details. For example, including descriptions such as "A middle-aged woman appears on the screen" or "The speaker is currently gesturing to the participants" will make it easier for disabled users to understand the content.
References
- WCAG 2.0 - Level A / 1.2.3
Example
In the example site, there is a description available for the video used. The video description should not only include the audio content of the video but also mention other events on the screen.
Information and Relationships
Principle
The page structure should be designed in a way that can be understood and used by disabled users.
Description
When determining the page structure on websites, designs that can be perceived by user agents or programs such as screen readers should be preferred. Navigation elements and links on the site should be grouped in a meaningful and distinguishable manner, and page content should be appropriately titled for clarity.
References
- WCAG 2.0 - Level A / 1.3.1
Example
In the example site, the content is grouped by using headings. Proper titling and structuring of content on the website will make it easier for users to navigate. Having the headings relevant to the content will enhance accessibility.
Meaningful Sequence
Principle
When the order in which page content is presented affects its meaning, the appropriate sequence should be clearly indicated.
Description
If a specific order for reading website content is desired, the source code should be created to take this into account. Ensuring that screen reader programs can determine the correct sequence to present content meaningfully to the user is important.
References
- WCAG 2.0 - Level A / 1.3.2
Example
As shown in the example image, meaningful sequencing of content used on websites will allow screen readers to read this content in the correct order.
Sensory Characteristics
Principle
When providing descriptions for content, do not rely solely on specific sensory characteristics.
Description
When explaining content or actions on websites, it is important not to rely solely on sensory characteristics like shape, size, visual position, orientation, or sound. For example, the phrase "Click the green button to proceed to the next step" would be meaningless to visually impaired users. Therefore, site content, navigation elements, links, and buttons should include clear and understandable descriptions that take into account users with various disabilities.
References
- WCAG 2.0 - Level A / 1.3.3
Example
In the example site, a clear and understandable directive has been prepared for the "Next" button.
Color Usage
Principle
Care should be taken in the use of color to ensure that content can be distinguished or correctly understood.
Description
It should be avoided that the contents or navigation elements on the websites should be distinguishable only through their colours. The information to be given in the site content should not be based only on colour codes, and users who may have problems in perceiving colours (e.g. visually impaired users, colour blind users, etc.) should be taken into consideration.
References
- WCAG 2.0 - Level A / 1.4.1
Example
In the example site, the graphic used is represented using both different colors and different shapes. Using descriptions in the website only with different colors may not be sufficient, considering colorblind users. Different shapes should also be used to accommodate users with color vision deficiencies.
Audio Control
Principle
Audio elements should be controllable by users.
Description
In cases where audio elements on websites last for more than 3 seconds, users should be able to stop or close the relevant element. It should be noted that audio elements that open automatically without user consent, such as background sounds or sounds, can disturb users accessing the website with screen reader programs. Instead of audio elements starting automatically when site content is loaded, users should be able to start them by choice. The use of background sounds should be avoided unless chosen by users.
References
- WCAG 2.0 - Level A / 1.4.2
Example
In the example site, users are provided with the ability to control the video content. The function to mute the sound used in the content can be easily found with a clear and accessible expression.
Keyboard
Principle
All content and actions on websites should be accessible by keyboard.
Description
Disabled users are expected to be able to use all the content and actions on websites seamlessly with a keyboard. For example, data entry screens should allow data entry using the Enter key and enable navigation between data entry fields using the Tab key. The ability to perform operations using only the keyboard is particularly useful for visually impaired users, users who cannot coordinate their hands and eyes, and users who cannot use a mouse due to hand tremors. However, operations that require handwriting input or mouse usage may be considered exceptions.
References
- WCAG 2.0 - Level A / 2.1.1
Example
In the example image, the help option should not be accessible only with a mouse. Keyboard keys should also be assigned to these functions to allow users who cannot use a mouse and use the website through the keyboard to access this content.
No Keyboard Traps
Principle
Keyboard usage should encompass all content and actions on the website.
Description
When designing content and actions on websites, consideration should be given to users who access website content using only a keyboard. Users should be able to use keyboard keys to control or close dialog boxes and pop-up windows.
References
- WCAG 2.0 - Level A / 2.1.2
Example
In the example site, the "OK" and "Cancel" buttons in the pop-up window can be used with the keyboard. Alert messages, informational messages, and pop-up windows used on websites should be closable with the keyboard, not just the mouse.
Adjustable Time
Principle
Users should be given sufficient time to read content or use it.
Description
There should be no time limits for actions on websites. However, in cases where time-limited actions exist, users should be informed about the time limit. Users should be able to stop the time limit or extend the given time in order to complete their actions. It is recommended to inform users before time runs out, give users 20 seconds to extend the time limit, allow the time limit to be extended up to ten times the default value, and make the extension process simple (e.g., using the space bar).
References
- WCAG 2.0 - Level A / 2.2.1
Example
In the example site, users are expected to be given the option to extend the time allotted to them. In time-limited actions on websites (e.g., making a choice, placing an order, entering information, etc.), users should be allowed to extend this time.
Pause, Stop, Hide
Principle
User-controllable functionality should be provided for moving, blinking, or scrolling content.
Description
On websites, if moving, blinking, or scrolling content lasts for more than five seconds, users should be able to pause, stop, or hide this content. Additionally, in cases where site content is automatically updated, automatic updates can be disabled to avoid negatively impacting the performance of screen reader programs.
References
- WCAG 2.0 - Level A / 2.2.2
Example
In the example site, an option to stop the content that moves automatically is provided to users.
Three times or Less Flashing Threshold
Principle
Content should be designed in a way that does not trigger health issues.
Description
Flashing content on websites can be a trigger for some users to have seizures. Therefore, flashing content should not flash more than three times per second, and content should be designed with small sizes and non-bright colors. To minimize the risk for people with epilepsy, it is recommended not to use flashing content unless absolutely necessary.
References
- WCAG 2.0 - Level A / 2.3.1
Example
In the example, the images are animated and contain more than three flashes per second. These images can create psychological problems for some users. Therefore, images used on websites should be selected carefully, avoiding images that may negatively affect users' health conditions.
Skipping Blocks
Principle
Repeated content should be skippable.
Description
Users should be provided with the option to skip repeated content that appears on different pages of a website. For example, having navigation elements at the beginning of each page that are read again by screen reader software on every page can be tedious for users accessing the website through screen readers. Therefore, users should be able to skip repeated content as needed.
References
- WCAG 2.0 - Level A / 2.4.1
Example
In websites, frequently repeated elements being read by screen readers each time can be bothersome to the user. For instance, menus appear on every page, and screen readers start reading from the top of the page. Adding a "Skip to Content" feature at the top of the page can help avoid the repeated reading of menus.
Topic-Titled Page
Principle
Clear and understandable page titles should be provided.
Description
Websites should include descriptive and meaningful page titles. This allows users to understand page content and distinguish between different web pages open in their browsers.
References
- WCAG 2.0 - Level A / 2.4.2
Example
In the example website, clear and understandable page titles are provided. Properly titling web pages to be relevant to their content helps screen readers accurately convey to users which page they are on.
Focus Order
Principle
Attention should be given to the logical sequence of content.
Description
When creating HTML code for website content, it is essential to arrange content logically and meaningfully. Properly sequencing content is important to ensure that users accessing the content via screen reader software can understand it accurately and completely. This is especially crucial in data entry screens and forms, where the navigation between input fields should be designed in a user-friendly sequence to prevent confusion.
References
- WCAG 2.0 - Level A / 2.4.3
Example
In the example website, the registration form is designed to be accessible using the keyboard only, taking into consideration the situations where users may want to navigate using the Tab key, ensuring that they move to the next field in sequence.
Link Purpose
Principle
Links should be named in a way that is meaningful and consistent with the content they are associated with.
Description
Link names on websites should be descriptive, clear, and understandable. Link names should provide information about the page to be displayed or the action to be performed when the link is clicked, and should avoid names that would cause confusion or lack of understanding.
References
- WCAG 2.0 - Level A / 2.4.4
Example
In the example website, the link is designed to be descriptive and relevant to the associated content.
Page Language
Principle
The language of the page's content should be programmatically determined.
Description
The spoken language used on websites should be clearly specified in the HTML code. Failure to indicate the language used on the site can lead to mispronunciations by screen readers, incorrect interpretation of content by user agents, and the display of alternative text in the wrong language.
References
- WCAG 2.0 - Level A / 3.1.1
Example
In the example website, the language of the page's content is specified in the source code. To ensure that screen readers can accurately read the content on websites, it's essential to indicate the language in which the content is authored in the HTML code.
In Focus
Principle
There should be no change of context when users focus on an element.
Description
On websites, when users focus on an element, changes in context should not be allowed. For example, if pressing the Tab key in a data entry screen opens a new dialog box, it can cause confusion for users. Therefore, elements other than the focused element should only become active when users make a selection.
References
- WCAG 2.0 - Level A / 3.2.1
Example
In the example images, you can see that the same action can be performed in different ways. In the top image, when you click on the data entry field, a help window automatically opens. However, for a user who navigates the website using only the keyboard and without a mouse, obtaining this help information is not possible in the first image. To address this, an option for accessing help using the keyboard should be provided.
For Input
Principle
Users should be informed about the actions or changes that will occur as a result of the data they enter or the links they click.
Description
On websites, users should be informed and not automatically redirected to a new page or have their content updated when they click on an element or make data entries. For instance, automatically selecting the item when clicking on an item in a drop-down menu or when navigating between elements using arrow keys can cause confusion for disabled users. Instead, it is recommended to provide buttons that allow users to confirm their selection.
References
- WCAG 2.0 - Level A / 3.2.2
Example
In the example image, clicking the "Select" button is required to complete the selection. Automatically completing the action when an item is chosen from the list can lead to user errors. Therefore, using a separate control element to confirm the selection would be helpful.
Error Identification
Principle
Users should be able to recognize when they make errors.
Description
Users who make errors should be able to understand that they have made a mistake and be informed about the reasons for the error. It should be considered that users accessing the website through screen reader programs, and similar tools, may not be able to perceive that they have made an error. Therefore, error messages should be presented in a textual format and should contain clear and meaningful expressions that users can understand.
References
- WCAG 2.0 - Level A / 3.3.1
Example
In the example website, users who made an incorrect entry have been informed. In internet websites, users should be informed with clear and understandable messages when they make errors in their actions.
Labels and Usage Instructions
Principle
Explanatory labels and instructions should be provided for data entry fields.
Description
To prevent confusion and errors when users with disabilities enter data, appropriate data field labels and guiding explanations should be provided. The purpose of data entry and the format in which the data should be entered must be understandable to users.
References
- WCAG 2.0 - Level A / 3.3.2
Example
In the example website, it is explained to users in which format the phone information should be entered.
Parsing
Principle
Site content must be distinguishable.
Description
The content of a website should be coded in a way that user agents and screen reader programs can distinguish and read it smoothly. For example, appropriate start and end tags must be placed for all elements in the HTML code. This ensures that assistive technologies can read the site content fully and accurately.
References
- WCAG 2.0 - Level A / 4.1.1
Example
Screen readers read website content through HTML codes. Therefore, using HTML codes without errors will help users with disabilities to use websites more effectively. As seen in the example image, all opened HTML tags must be closed.
Name, Role, Value
Principle
All elements should have names, roles, and values.
Description
It is expected that all the elements in the websites should have name, role and value features. For this purpose, HTML codes of web sites should be developed by considering the related standards. For example, using a label instead of a tag for a button will cause screen reader programmes to perceive buttons as images. Therefore, the correct roles for all elements should be determined with appropriate HTML tags. In addition, it is important that all elements are named in such a way that they are distinguishable so that users can understand the purpose and function of the elements.
References
- WCAG 2.0 - Level A / 4.1.2
Example
In the example website, the appropriate "button" tag is used for the "Submit" button. When it comes to screens with data input, it is important to pay attention to the correct usage of HTML tags, careful naming of form elements, ensuring labels are unique, and other similar considerations.
Keyboard Shortcuts
Principle
Keyboard shortcuts provided by a website for specific components should only be active when the relevant component is in focus, should be able to be deactivated when necessary, and should be customizable.
Description
Keyboard shortcuts used to facilitate navigation without using a mouse on website content should be capable of being disabled for users who will not or cannot use these shortcuts. It is expected that when a user focuses on a user interface component within a website, only the shortcuts relevant to that component should be active.
References
- WCAG 2.1 - Level A / 2.1.4
Example
A mechanism should be provided to allow users to disable keyboard shortcuts. This way, users who operate with speech input can disable one-key shortcuts from being triggered by words captured by the microphone. Additionally, a mechanism should be provided to allow users to customize shortcuts.
Pointer (Cursor) Movements
Principle
All actions that require multi-touch gestures or moving the pointer/finger in a specific direction should, unless necessary, be executable using different pointing devices and simple inputs.
Description
Pointers can take various forms, including fingers, stylus pens, laptop touchpads, mice, or game controllers. Actions that require moving the pointer in a specific direction involve user interaction that relies not only on the endpoints but also on the path followed by the pointer or finger. To accommodate users who may have difficulty performing complex movements, a structure should be designed that allows access to content through simple actions.
Examples of scrolling movements include dragging a slider control in a designated direction within a defined input area or moving the pointer according to a specified shape on the screen. Multiple touch gestures may involve actions such as zooming by simultaneously sliding two fingers, touching the screen with one finger while sliding another, or performing double taps.
This guideline applies to pointer actions provided through web content. It does not encompass actions required for using browsers and assistive technologies for accessibility. Furthermore, free-form drag-and-drop actions are not covered by this principle.
References
- WCAG 2.1 - Level A / 2.5.1
Example
In the example website, there is a plus (+) button for zooming in on the map. Users can perform the zoom operation with a single movement.
Pointer Cancellation
Principle
The pointer should activate appropriately depending on the nature of the action to be taken on a web page, and there should be an option for canceling actions that may be accidentally performed.
Description
Users can accidentally click or tap on an element or control on a web page. In such cases, an option to cancel the action or undo it should be provided. If a user realizes they've made a mistake after clicking an element, they should be able to cancel the action by moving the pointer away from the target without lifting their finger from the screen or releasing the left mouse button.
Individuals with various disabilities may have initiated a mouse or touch action unintentionally that results in undesired outcomes. Below are methods to cancel different actions for users:
- Cancellation on release action: The easiest way to cancel a pointer action is for the action to occur when the pointer is released. In touch screen interaction, the action should only activate when the finger is removed from the screen within the boundaries of the target. In mouse interaction, the action should only activate when the left button is released while inside the target boundaries.
- Cancellation or undo on release action: In cases where a simple click is required for the action to activate, releasing the left mouse button should naturally result in the cancellation of the action. This is commonly seen in drag-and-drop actions.
- Reverse action on release action: In this type of action, the action is activated when pressed or clicked and is canceled or reversed when released. An example is when clicking on an element on the page temporarily displays a pop-up window that disappears when released.
- Completion on click action: Actions that require a press or click to be fully activated, where the action is complete and doesn't need to be canceled or undone. A common example is the use of a physical keyboard, where pressing a key immediately displays the corresponding character on the screen. If this expected behavior of standard keyboards is altered by software so that the character only appears on release, it would be an unexpected and problematic situation for users.
References
- WCAG 2.1 - Level A / 2.5.2
Example
In user interfaces where a single tap or long press is required, lifting the finger from the screen within the visual boundaries of that element is necessary to trigger the relevant action.
Including the Name Used in Labels
Principle
Accessible names of interface components should include their visible labels.
Description
Elements on websites have both a visual label that identifies them and a programmed label name used for accessibility by assistive technology tools. When there is a mismatch between the visible label and the accessible name, it can lead to various issues when systems vocalize the labels and users provide voice commands based on these labels. To prevent such issues, the accessible names of elements should match or include the visible label names.
References
- WCAG 2.1 - Level A / 2.5.3
Example
- The accessible name of the element matches its visible label name.
- The accessible name of the element begins with the visible label name.
Action by Motion
Principle
Functions that can be activated by moving devices (such as shaking or rotating) or by user's hand-arm and body movements (interpreted by motion sensors like cameras) should also be operable with more traditional interface components unless motion is essential for performing the function.
Description
Mobile devices like tablets and phones come with sensors that provide inputs like accelerometers and gyroscopes. These sensors enable users to perform certain functions by moving the device or making specific motions. Some users may not be able to perform the required motion or may have physical barriers that inadvertently trigger a motion. Therefore, functions dependent on motion should be able to be turned off, and additional methods to perform these functions should be provided. Some applications are specifically designed to work with device sensors. An example outside the scope of this principle could be a step counter application where device motion generates input.
References
- WCAG 2.1 - Level A / 2.5.4
Example
- After entering data into a text field, a dialog box appears that allows users to undo the action they performed by shaking the device. Additionally, a "cancel" button providing the same function is located next to the text field.
- Users can navigate to the previous or next page by tilting the device sideways. Buttons or links offering the same functions are also available on the page.
