Digital A11y

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)

This success criterion requires that the commonly repeated navigation
related user interface elements like skip to main content link, primary
secondary navigation links, logo, search element etc must be placed at the
same locations where they occur on each page they are repeated. The
placement of these user interface components is very important as people
with disabilities heavily rely on common components for quick navigation.
Users with cognitive & intellectual disabilities, users who use screen
magnification technology & text to speech software’s must be able to predict
the existence of the common components. For example, if a few pages
contains, a search element is placed on the top right and in other pages,
the search component is not placed in the same location, this will fail this
Success Criterion. Sc3.2.3.

Providing consistent navigation does restrict content authors or developers
from adding secondary navigation or additional components into the layout of
the page. For example, a navigational menu might have sub menus that are
exposed when the user is on that particular navigational menu. But here the
order must not change the order of the navigation menu while the submenus
are added in between them. Focus of the keyboard/assistive aid user must go
to each menu during navigation.

Points To Remember

• keep navigational menus in the same location.
• present the navigational menus in the same order on all pages.
• Represent all the standard elements like logo, search functionality, and skip links etc. in the same location on all the pages.
• using a standard template will help achieve to pass the success criteria of 3.2.3 consistent navigation.

References

Understanding Success Criterion 3.2.3

Continue reading Understanding SC 3.2.3 Consistent Navigation

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)

This success criterion conveys that change of context should not occur while user is trying to input data. For example, if the user is filling a form & if the page refreshes while selecting an option in <select> element or if the form submits after the user fills in the last form field, it fails this checkpoint. User should be provided with an option to submit the form by providing a submit button or hint/instruction should be provided for all users informing that form will submit once the form fields are filled

Exceptions

There are some exceptions to this success criterion. Change of content is not change of context. For example if a radio button is selected & if it triggers more form controls it is not change of context. Here content is updating. Activating links, buttons or tab controls doesn’t fall into on input category. Here is user is taking deliberate action to trigger these form controls…

Points to Remember

• Make sure that forms don’t submit on input of data.
• Make sure that focus doesn’t move to next form control once a form field is populated with data.
• Provide a submit button for all forms.
• Make sure that control of how data is populated is in the hands of your users.
• If there is a change of context, then provide an instruction that is available for all user groups.

References

Understanding Success Criterion 3.2.2

Continue reading Understanding SC 3.2.2 on Input

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)

The intent of this success criterion is to make sure that any unwanted actions are not initiated when focus moves on to an element. For example during tab navigation or shift tab navigation if user focus moves on to a link & a modal is triggered this fails this check point. Here user did not initiate this action; it was initiated when user focus moved on to a particular element. If the website is built using HTML & CSS purely, we will not encounter such behavior. This behavior is seen a lot on websites built with fancy scripting where the developers have no knowledge about accessibility. We must also take mouse users into consideration while testing for this checkpoint; while mouse pointer moves onto elements no actions should be initiated.

Ensure that:

• Links don’t open new page or new window when focused with mouse or keyboard.
• Forms don’t submit automatically.
• There are no pop-ups or modal windows opening on pageload or focusing on an element.
• Focus should not move automatically to another element where it disorients the users.

Points to Remember

• Ensure that no element changes by receiving focus.
• We should avoid both visual & behavioral modifications to page.
• A website built using only HTML & CSS will not have on focus by default, one needs to provide this through scripting.
• One way to test this check point is to unplug the mouse & navigate the page using the keyboard.

Exceptions

• Elements can change on focus if the context doesn’t change. For example, you can use a dynamic menu on your website, the kind where navigation options drop down when you hover over an item. This is not a change of context.
• Another example would be a hover status on a link, again, this isn’t a change of context.

References

Understanding Success Criterion 3.2.1

Continue reading Understanding SC 3.2.1 on Focus

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA).

This success criterion requires that the contents written in multiple languages on the same web page has the human language defined in a programmatically determinable way. In other words, where the default language of the page is, say English but the page has phrases, sentences, paragraphs or passages from any other language, then the secondary language of such texts must be programmatically determined.

Exceptions

• Any words that are adopted into the default language and that is part of a phrase or immediately surrounding text need not meet this criterion
• Technical terms can be ignored.

Benefits

• Visual browsers would be able to display correct characters for the language of parts and change the reading order for the languages that have right to left reading
• Braille translating software would be able to provide correct Braille characters and contractions
• Screen readers would be able to switch to apt pronunciation rules
• Traditional browsers would be able to process the texts aptly
• Machine based translation technologies would be able to translate the texts from one language into another when there is a change of language
• In the modern browsers, when such secondary language texts occur, users would be able to look up the meaning using a dictionary.

Points to ponder

• Ensure to use appropriate language code (lan=”fr”) wherever the text is in other language
• Ensure appropriate language token is used in the lang attribute (lang=”pt-br”).
• Beware of the exceptions too.

References

Understanding Success Criterion 3.1.2

Continue reading Understanding SC 3.1.2 Language of Parts

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

This success criterion requires that each web page of a site has its default human language programmatically defined. This, according to the Internationalization best practices plays a critical role in determining the default text-processing language. Apart from this, this is a key factor for screen readers to switch to the correct reading language, load correct pronunciation rules of language variations. Traditional browsers can render the text correctly and visual browsers can load characters and scripts appropriately. Thus language of page helps people with disabilities understand content in a better way.

Points to Ponder

• Ensure each page of your web site has lang attribute
• Ensure the language code is correct
• Use appropriate language tokens in terms of language variations like lang=en-us” for English in US and lang=”en-uk” for English in Britain.

References

Understanding Success Criterion 3.1.1

Continue reading Understanding SC 3.1.1 Language of Page