Difference between revisions of "UniWiki:Manual of Style/Accessibility"

From EVE University Wiki
Jump to: navigation, search
 
(21 intermediate revisions by 2 users not shown)
Line 53: Line 53:
 
** [http://colorfilter.wickline.org/?j=1;t=a Colorfilter.wickline.org] or [http://www.vischeck.com/vischeck/vischeckURL.php vischeck.com] are tools for simulating color blind vision.
 
** [http://colorfilter.wickline.org/?j=1;t=a Colorfilter.wickline.org] or [http://www.vischeck.com/vischeck/vischeckURL.php vischeck.com] are tools for simulating color blind vision.
  
== Block elements ==
+
= Block elements =
  
=== Lists ===
+
== Lists ==
{{see also|Help:Lists}}
+
''See also: [[Wikipedia:Help:Lists|Wikipedia:Lists]]
{{shortcut|MOS:LISTGAP}}
 
  
Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a [[description list]] (a list made with a leading colon) or an [[unordered list]]. Lists are meant to group elements that belong together, but [[MediaWiki]] will interpret the blank line as the end of one list and start a new one. These excessive double line breaks also disrupt [[screen reader]]s, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding lists starting at the highest level.
+
Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a [[Wikipedia:Description list|description list]] (a list made with a leading colon) or an [[Wikipedia:Unordered list|unordered list]]. These excessive double line breaks also disrupt [[Wikipedia:Screen reader|screen readers]], which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding lists starting at the highest level.
  
For example, in a discussion, do {{tick}} this best practice:
+
For example, in a discussion, {{dothis|do this best practice:}}
  
 
<pre>
 
<pre>
Line 68: Line 67:
 
</pre>
 
</pre>
  
or {{tick}} this acceptable practice:
+
or {{dothis|this acceptable practice:}}
  
 
<pre>
 
<pre>
Line 75: Line 74:
 
</pre>
 
</pre>
  
but {{cross}} don't do this:
+
but {{notthis|don't do this:}}
  
 
<pre>
 
<pre>
Line 82: Line 81:
 
</pre>
 
</pre>
  
or {{cross}} this:
+
or {{notthis|this:}}
  
 
<pre>
 
<pre>
Line 90: Line 89:
 
</pre>
 
</pre>
  
==== Indentation ====
+
=== Indentation ===
{{see also|Wikipedia:Indentation|l1=Indentation}}
+
:''See also [[Wikipedia:Wikipedia:Indentation|Wikipedia:Indentation]]''
{{shortcut|MOS:INDENTGAP}}
 
  
 
Colons (:) at the start of a line mark that line as part of an HTML definition list.  The visual effect in most web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on Talk pages.  This is not ideal for accessibility or semantics, but is currently in wide use. Blank lines should not be placed between indented lines of text, as they are interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance:
 
Colons (:) at the start of a line mark that line as part of an HTML definition list.  The visual effect in most web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on Talk pages.  This is not ideal for accessibility or semantics, but is currently in wide use. Blank lines should not be placed between indented lines of text, as they are interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance:
Line 102: Line 100:
 
</pre>
 
</pre>
  
==== Vertical lists ====
+
=== Bulleted vertical lists ===
 
+
For bulleted vertical lists, do not separate items by leaving blank lines between them. If list items are separated by more than one line break, the [[Wikipedia:WP:HTML|HTML]] list will be ended before the line break, and another HTML list will be opened after the line break. This effectively breaks what is seen as one list into several smaller lists for those using [[Wikipedia:Screen reader|screen readers]]. For example, for the coding:
===== Bulleted vertical lists =====
 
For bulleted vertical lists, do not separate items by leaving blank lines between them. If list items are separated by more than one line break, the [[WP:HTML|HTML]] list will be ended before the line break, and another HTML list will be opened after the line break. This effectively breaks what is seen as one list into several smaller lists for those using [[screen reader]]s. For example, for the coding:
 
  
 
<pre>* White rose
 
<pre>* White rose
Line 124: Line 120:
 
but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end."
 
but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end."
  
Do not separate list items with line breaks ({{tag|br|o}}). Use {{tl|plainlist}} / {{tl|unbulleted list}} if the list is to remain vertical; or consider {{tl|flatlist}} / {{tl|hlist}} if the list could be better rendered horizontally (in-line) as described in the following two sections.
+
Do not separate list items with line breaks ({{tag|br|o}}).
 
 
===== <span id="Unbulleted (vertical) lists"></span>Unbulleted vertical lists =====
 
<!-- This Anchor tag serves to provide a permanent target for incoming section links. Please do not move it out of the section heading, even though it disrupts edit summary generation (you can manually fix the edit summary before saving your changes). Please do not modify it, even if you modify the section title. It is always best to anchor an old section header that has been changed so that links to it won't be broken. See [[Template:Anchor]] for details. (This text: [[Template:Anchor comment]]) -->
 
{{shortcut|MOS:PLIST|MOS:VLIST}}
 
 
 
For unbulleted lists running down the page, the templates {{tl|plainlist}} and {{tl|unbulleted list}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list rather than including {{Tag|br|single}} line breaks, which should not be used—see above. They differ only in the wiki-markup used to create the list. Note that because these are templates, the text of each list item cannot contain the vertical bar symbol ( | ) unless it is replaced by <code><nowiki>{{!}}</nowiki></code> or is contained within {{tag|nowiki}} tags.
 
{| class="wikitable"
 
|+ Example of plainlist
 
! style="width:11.7em;" | Wikitext
 
! style="width:11.7em;" | Renders as
 
|-
 
| <pre style="line-height:1.2em;">{{plainlist |
 
* White rose
 
* Yellow rose
 
* Pink rose
 
* Red rose
 
}}</pre>
 
| {{plainlist |
 
* White rose
 
* Yellow rose
 
* Pink rose
 
* Red rose
 
}}
 
|}
 
 
 
{| class="wikitable"
 
|+ Example of unbulleted list
 
! style="width:11.7em;" | Wikitext
 
! style="width:11.7em;" | Renders as
 
|-
 
| <pre style="line-height:1.2em;">{{unbulleted list
 
| White rose
 
| Yellow rose
 
| Pink rose
 
| Red rose
 
}}</pre>
 
| {{unbulleted list
 
| White rose
 
| Yellow rose
 
| Pink rose
 
| Red rose
 
}}
 
|}
 
 
 
Alternatively, in templates such as Navboxes and the like, or any suitable container, such lists may be styled with the class "<code>plainlist</code>", thus:
 
 
 
{{plainlist |
 
* <code><nowiki>| listclass = plainlist</nowiki></code> or
 
* <code><nowiki>| bodyclass = plainlist</nowiki></code>
 
}}
 
 
 
In infoboxes:
 
{{plainlist |
 
* <code><nowiki>| rowclass = plainlist</nowiki></code> or
 
* <code><nowiki>| bodyclass = plainlist</nowiki></code>
 
}}
 
 
 
may be used. See also [[Wikipedia:Manual of Style/Lists#Unbulleted lists|Manual of Style: Lists § Unbulleted lists]]. See [[WP:NAV]] for more details on Navigation templates.
 
 
 
==== Horizontal lists ====
 
{{shortcut|MOS:HLIST}}
 
 
 
For lists running across the page, and in single rows in infoboxes and other tables, the templates {{tl|flatlist}} and {{tl|hlist}} ("h[orizontal]list") are available to improve accessibility and semantic meaningfulness. This feature makes use of the correct HTML markup for each list item, rather than including bullet characters which, for example, are read out (e.g., "dot cat dot dog dot horse dot...") by the assistive software used by people who are blind. The templates differ only in the wiki-markup used to create the list. Note that because these are templates, the text of each list item cannot contain the vertical bar symbol ( | ) unless it is replaced by <code><nowiki>{{!}}</nowiki></code> or is contained within {{tag|nowiki}} tags.
 
  
<!-- The following examples deliberately wrap the list over two lines to show the position of the list separator.
+
== Tables ==
Please don't widen them. -->
 
{| class="wikitable"
 
|+ Example of flatlist
 
! style="width:11.7em;" | Wikitext
 
! style="width:11.7em;" | Renders as
 
|-
 
| <pre style="line-height:1.2em;">{{flatlist |
 
* White rose
 
* Yellow rose
 
* Pink rose
 
* Red rose
 
}}</pre>
 
| {{flatlist |
 
* White rose
 
* Yellow rose
 
* Pink rose
 
* Red rose
 
}}
 
|}
 
 
 
{| class="wikitable"
 
|+ Example of hlist
 
! style="width:11.7em;" | Wikitext
 
! style="width:11.7em;" | Renders as
 
|-
 
| <pre style="line-height:1.2em;">{{hlist
 
| White rose
 
| Yellow rose
 
| Pink rose
 
| Red rose
 
}}</pre>
 
| {{hlist
 
| White rose
 
| Yellow rose
 
| Pink rose
 
| Red rose
 
}}
 
|}
 
 
 
Alternatively, in templates such as Navboxes and the like, or any suitable container, such lists may be styled with the class <code>hlist</code>, thus:
 
{{plainlist |
 
* <code><nowiki>| listclass = hlist</nowiki></code> or
 
* <code><nowiki>| bodyclass = hlist</nowiki></code>
 
}}
 
 
 
In infoboxes:
 
{{plainlist |
 
* <code><nowiki>| rowclass = hlist</nowiki></code> or
 
* <code><nowiki>| bodyclass = hlist</nowiki></code>
 
}}
 
 
 
may be used. {{crossref|See [[WP:NAV]] for more details on Navigation templates.}}
 
 
 
=== Tables ===
 
{{shortcut|MOS:DTAB}}
 
 
Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them.
 
Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them.
  
Use the correct wikitable pipe syntax to take advantage of all the features available. See [[meta:Help:Tables]] for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background colour).
+
Use the correct wikitable pipe syntax to take advantage of all the features available. See [https://meta.wikimedia.org/wiki/Help:Table MetaWiki:Tables] for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background colour).
  
Many [[Wikipedia:Navigational templates|navboxes]], [[Wikipedia:Series templates|series]] templates, and [[Help:Infobox|infoboxes]] are made using tables.
+
Many [[Wikipedia:Wikipedia:Navigational templates|navboxes]], [[Wikipedia:Wikipedia:Series templates|series]] templates, and [[Wikipedia:Help:Infobox|infoboxes]] are made using tables.
  
Avoid using {{tag|br|single}} tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row. [[Wikipedia:WikiProject Accessibility/Infobox accessibility|WikiProject Accessibility/Infobox accessibility]] has been addressing this problem.
+
Avoid using {{tag|br|single}} tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row.
  
 
==== Data tables ====
 
==== Data tables ====
{{Main article|Wikipedia:Manual of Style/Accessibility/Data tables tutorial}}
+
:''See also: [[Wikipedia:Wikipedia:Manual of Style/Accessibility/Data tables tutorial|Wikipedia:Data tables tutorial]]''
  
 
<pre>
 
<pre>
Line 273: Line 151:
 
</pre>
 
</pre>
  
; Caption ( <code>|+</code> ): A caption is a table's title, describing its nature.<ref name="H39" group="WCAG-TECH">[http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H39 H39: Using caption elements to associate data table captions with data tables], A accessibility level.</ref>
+
; Caption ( <code>|+</code> ): A caption is a table's title, describing its nature.
; Row & column headers (<code> ! </code>): Like the caption, these help present the information in a logical structure to visitors.<ref group="WCAG-TECH">{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H51 | title = H51: Using table markup to present tabular information| accessdate = 1 January 2011| publisher = [[W3C]]}}</ref> The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.<ref>{{Cite web | url = http://www.w3.org/TR/REC-html40/struct/tables.html#edef-TH | title= Table cells: The TH and TD elements | work = Techniques for WCAG 2.0 | publisher = [[W3C]] | accessdate = 1 January 2011}}</ref>
+
; Row & column headers (<code> ! </code>): Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.
; Scope of headers (<code> ! scope="col" | and ! scope="row" | </code>): This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.<ref name="H63" group="WCAG-TECH">{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H63.html | title = H63: Using the scope attribute to associate header cells and data cells in data tables| work = Techniques for WCAG 2.0 | accessdate = 1 January 2011| publisher = [[W3C]]}}</ref>
+
; Scope of headers (<code> ! scope="col" | and ! scope="row" | </code>): This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.
  
[[Wikipedia:Manual of Style/Accessibility/Data tables tutorial]] provides detailed requirements about:
+
[[Wikipedia:Wikipedia:Manual of Style/Accessibility/Data tables tutorial|Wikipedia's data tables tutorial]] provides detailed requirements about:
 
# Correct table captions
 
# Correct table captions
 
# Correct headers structure
 
# Correct headers structure
Line 284: Line 162:
  
 
==== Layout tables ====
 
==== Layout tables ====
{{shortcut|WP:LTAB}}
 
  
Avoid using tables for layout purposes only. The best option is to use [[HTML]]'s <code>&lt;div&gt;</code> blocks and style attributes because they provide flexibility.
+
Avoid using tables for layout purposes only. The best option is to use [[Wikipedia:HTML|HTML]]'s <code>&lt;div&gt;</code> blocks and style attributes because they provide flexibility.
  
 
For simple layouts, tables can be an option. Especially if the only point of the table is to get a floating effect, then <code>align="right"</code> etc. will work with some browsers [[#Users with limited CSS/JavaScript support|not supporting CSS]] at all. This is in fact a verbose approximation of <code>&lt;div&gt;</code> plus CSS, and not the design sin known as (nested) "table layout".
 
For simple layouts, tables can be an option. Especially if the only point of the table is to get a floating effect, then <code>align="right"</code> etc. will work with some browsers [[#Users with limited CSS/JavaScript support|not supporting CSS]] at all. This is in fact a verbose approximation of <code>&lt;div&gt;</code> plus CSS, and not the design sin known as (nested) "table layout".
Line 302: Line 179:
 
</pre>
 
</pre>
  
== Images ==
+
= Images =
{{Shortcut|WP:ACCIM}}
+
:''Further information: [[Wikipedia:Wikipedia:Alternative text for images|Wikipedia:Alternative text for images]], [[UniWiki:Manual of Style#Images]], [[Wikipedia:Wikipedia:Image use policy#Size|Wikipedia:Image use policy#Size]]''
{{Further|Wikipedia:Alternative text for images|Wikipedia:Manual of Style#Images|Wikipedia:Image use policy#Size}}
 
  
# Images should include an [[alt attribute]] that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added it should be succinct, or should refer the reader to the caption or adjacent text: see [[WP:ALT]] for more information.
+
# Images should include an [[Wikipedia:Alt attribute|alt attribute]] that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added it should be succinct, or should refer the reader to the caption or adjacent text: see [[Wikipedia:WP:ALT|Wikipedia:Alternative text for imates]] for more information.
# In [[Wikipedia:Manual of Style/Captions#Special situations|most cases]], images should contain a [[Wikipedia:Manual of Style/Captions|caption]] using the built in image syntax. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
+
# In [[UniWiki:Manual of Style/Captions#Special situations|most cases]], images should contain a [[UniWiki:Manual of Style/Captions|caption]] using the built in image syntax. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
 
# Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
 
# Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
 
# Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
 
# Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
# Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading nor at the end of the previous section, otherwise screen readers would read the image (and its textual alternative) in a different section; as they would appear to viewers of the mobile site. See [[Wikipedia:Picture tutorial]] for more information.
+
# Images should be inside the section they belong to (after the heading and after any links to other articles), and not at the end of the previous section, otherwise screen readers would read the image (and its textual alternative) in a different section; as they would appear to viewers of the mobile site. See [[Wikipedia:Wikipedia:Picture tutorial|Wikipedia:Picture tutorial]] for more information.
 
# Avoid referring to images as being on the left or right. Image placement is different for viewers of  the mobile version of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images.
 
# Avoid referring to images as being on the left or right. Image placement is different for viewers of  the mobile version of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images.
# This guideline includes alt text for LaTeX-formatted equations in <nowiki><math></nowiki> mode.
 
  
== Animations, videos and audio ==
+
= Animations, videos and audio =
{{Shortcut|MOS:ANIMATION}}
+
:''Further information: [[Wikipedia:Wikipedia:Media help|Wikipedia:Media help]], [[Wikipedia:Wikipedia:Creation and usage of media files|Wikipedia:Creation and usage of media files]]''
{{Further|Wikipedia:Media help|Wikipedia:Creation and usage of media files}}
 
  
=== Animations ===
+
== Animations ==
To be accessible, an animation ([[GIF]] – Graphics Interchange Format) should either:
+
To be accessible, an animation ([[Wikipedia:GIF|GIF]] – Graphics Interchange Format) should either:
* Not exceed a duration of five seconds (which results in making it a purely decorative element)<ref>{{Cite web| url =http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G152| title =  Setting animated gif images to stop blinking after n cycles (within 5 seconds)| work = Techniques for WCAG 2.0 | accessdate = 1 January 2011 | publisher = [[W3C]]}}</ref> or
+
* Not exceed a duration of five seconds (which results in making it a purely decorative element), or
* Be equipped with control functions (stop, pause, play)<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G4 | title = Allowing the content to be paused and restarted from where it was paused| accessdate = 1 January 2011| work = Techniques for WCAG 2.0 | publisher = [[W3C]]}}</ref>
+
* Be equipped with control functions (stop, pause, play)
  
 
This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial [//commons.wikimedia.org/w/index.php?title=Help_talk:Converting_video&oldid=39737985#Converting_an_animated_GIF converting animated GIFs to Theora OGG]).
 
This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial [//commons.wikimedia.org/w/index.php?title=Help_talk:Converting_video&oldid=39737985#Converting_an_animated_GIF converting animated GIFs to Theora OGG]).
  
In addition, animations '''''must not''''' produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.<ref name="wcag 2.0 gl2.3">{{cite web | url=http://www.w3.org/TR/2008/REC-WCAG20-20081211/#seizure-does-not-violate | title=Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures. | date=11 December 2008 | work=Web Content Accessibility Guidelines (WCAG) 2.0 | publisher=[[W3C]] | accessdate=28 May 2015}}</ref>
+
In addition, animations '''''must not''''' produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.
  
=== Video ===
+
== Video ==
Subtitles can be added to video, in [[Timed Text]] format. There is a corresponding help page at [[:commons:Commons:Video#Subtitles and closed captioning]]. Subtitles are meant for the transcription of speech.
+
Subtitles can be added to video, in [[Wikipedia:Timed Text|Timed Text]] format. There is a corresponding help page at [https://commons.wikimedia.org/wiki/Commons:Video#Subtitles_and_closed_captioning WikiMedia Commons:Video#Subtitles and closed captioning]. Subtitles are meant for the transcription of speech.
  
There is a need for [[closed captions]] for the hearing impaired. As of November 2012 this is not possible, but this feature could be easily added and has been requested in [[bugzilla:41694]]. Closed captions are meant to be viewed instead of subtitles. Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics.<ref>{{Cite web | url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G69 | title = Providing an alternative for time based media | work = Techniques for WCAG 2.0 | accessdate = 1 January 2011| publisher = [[W3C]]}}</ref> Off-Wikipedia guides should be consulted for how to create closed captions.<ref>Please see : [http://main.wgbh.org/wgbh/pages/mag/services/captioning/faq/sugg-styles-conv-faq.html A quick and basic reference for closed captions], [http://www.cab-acr.ca/english/social/captioning/captioning.pdf a detailed reference (PDF)] and [http://www.dcmp.org/captioningkey/index.html a list of best practices for closed captions].</ref>
+
There is a need for [[Wikipedia:Closed captions:closed captions]] for the hearing impaired. As of December 2016 this is not possible, but this feature could be added in the future. Closed captions are meant to be viewed instead of subtitles. Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics. Off-UniWiki guides should be consulted for how to create closed captions.<ref>Please see : [http://main.wgbh.org/wgbh/pages/mag/services/captioning/faq/sugg-styles-conv-faq.html A quick and basic reference for closed captions], [http://www.cab-acr.ca/english/social/captioning/captioning.pdf a detailed reference (PDF)] and [http://www.dcmp.org/captioningkey/index.html a list of best practices for closed captions].</ref>
  
A text version of the video would also be needed for the blind, but as of November 2012 there is no convenient way to provide alt text for videos.
+
A text version of the video would also be needed for the blind, but as of December 2016 there is no convenient way to provide alt text for videos.
  
=== Audio ===
+
== Audio ==
Subtitles for speech, lyrics, dialogue, etc.<ref>{{Cite web| url = http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G158 | title = Providing an alternative for time-based media for audio-only content| work = Techniques for WCAG 2.0 | publisher = [[W3C]]| accessdate = 1 January 2011}}</ref> can easily be added to audio files. The method is similar to that of the video: [[:commons:Commons:Video#Subtitles and closed captioning]].
+
Subtitles for speech, lyrics, dialogue, etc. can easily be added to audio files. The method is similar to that of the video: [https://commons.wikimedia.org/wiki/Commons:Video#Subtitles_and_closed_captioning WikiMedia Commons:Video#Subtitles and closed captioning].
  
== Styles and markup options ==
+
= Styles and markup options =
{{Shortcut|MOS:DEVIATIONS}}
 
  
 
=== Best practice: Use Wikimarkup and CSS classes in preference to alternatives ===
 
=== Best practice: Use Wikimarkup and CSS classes in preference to alternatives ===
In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. The site-wide CSS in [[MediaWiki:Common.css]] is more carefully tested to ensure accessibility (e.g. sufficient color contrast) and compatibility with a wide range of browsers. Moreover, it allows users with very specific needs to change the color schemes in their own style sheet ([[Special:MyPage/skin.css]], or their browser's style sheet). For example, a style sheet at [[Wikipedia:Style sheets for visually impaired users]] provides higher contrast backgrounds for [[WP:NAVBOX|navboxes]]. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose his/her own theme.
+
In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. It allows users with very specific needs to change the color schemes in their browser's style sheet. For example, a style sheet at [[Wikipedia:Wikipedia:Style sheets for visually impaired users|Wikipedia:Style sheets for visually impaired users]] provides higher contrast backgrounds for [[Wikipedia:WP:NAVBOX|navboxes]]. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose his/her own theme.
  
 
It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.
 
It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.
  
Regarding accessibility, deviations from standard conventions may be tolerated [[WP:COLOUR|so long as they are accessible]]. Members of the accessibility project have ensured that the default style is accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough [[WP:Colour contrast|color contrast]]. For instance, the infoboxes and [[Template:The Simpsons|navigational templates]] relating to ''[[The Simpsons]]'' use a yellow colour scheme, to tie in with the dominant colour in the series. In this case, blue links on yellow provides enough colour contrast, and thus is accessible.
+
Regarding accessibility, deviations from standard conventions may be tolerated [[UniWiki:Manual of Style/Accessibility#Color|so long as they are accessible]]. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough [[Wikipedia:WP:Colour contrast|color contrast]]. For instance, the infoboxes and [[Wikipedia:Template:The Simpsons|navigational templates]] relating to ''[[Wikipedia:The Simpsons|The Simpsons]]'' use a yellow colour scheme, to tie in with the dominant colour in the series. In this case, blue links on yellow provides enough colour contrast, and thus is accessible.
  
In general, articles should use [[wikimarkup]] in preference to the limited set of [[meta:Help:HTML_in_wikitext#Permitted_HTML|allowed HTML elements]]. In particular, do not use the HTML style elements {{tag|i|o}} and {{tag|b|o}} to format text; it is preferable to use Wiki-markup <code><nowiki>''</nowiki></code> or <code><nowiki>'''</nowiki></code> for purely typographic italicisation and boldfacing, respectively, and use [[Semantic HTML|semantic markup]] templates or elements for more meaningful differences.  The {{tag|font|o}} element should also be avoided in article text; use {{tlx|em}}, {{tlx|code}}, {{tlx|var}}, and our other [[:Category:Semantic markup templates|semantic markup templates]] as needed, to emphasise logical differences not just visual ones. Use the {{tl|small}} and the {{tl|big}} templates to change font size, rather than setting it explicitly with CSS style attributes like <code>font-size</code> or deprecated style elements like {{tag|small|o}}. Of course there are natural exceptions; e.g., it may be beneficial to use the {{tag|u}} element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally [[MOS:BADEMPHASIS|not used in article text]].
+
In general, articles should use [[Wikipedia:Help:Wikitext|Wikimarkup]] in preference to the limited set of [[Wikipedia:Help:HTML in wikitext|allowed HTML elements]]. In particular, do not use the HTML style elements {{tag|i|o}} and {{tag|b|o}} to format text; it is preferable to use Wiki-markup <code><nowiki>''</nowiki></code> or <code><nowiki>'''</nowiki></code> for purely typographic italicisation and boldfacing, respectively, and use [[Wikipedia:Category:Semantic markup templates|semantic markup templates]] or elements for more meaningful differences.  The {{tag|font|o}} element should also be avoided in article text to emphasise logical differences, not just visual ones.. Of course there are natural exceptions; e.g., it may be beneficial to use the {{tag|u}} element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally [[UniWiki:Manual of Style/Text formatting#How not to apply emphasis|not used in article text]].
  
 
=== Users with limited CSS or JavaScript support ===
 
=== Users with limited CSS or JavaScript support ===
{{anchor|Scrolling and collapsible sections|Users with limited CSS/JavaScript support}}<!--Old name, misusing slash; may be linked to from somewhere.-->
+
{{see also|UniWiki:Manual of Style#Scrolling lists and collapsible content}}
{{see also|Wikipedia:Manual of Style#Scrolling lists and collapsible content}}
 
  
Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for [[JavaScript]] or [[Cascading Style Sheets]]; remember that [[Wikipedia:Reusing Wikipedia content|Wikipedia content can be reused freely]] in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. This includes techniques such as the <code>[[Wikipedia:HiddenStructure|hiddenStructure]]</code> method for hiding table content (which produces incomprehensible output without CSS) and some implementations of the <code>NavFrame</code> collapsing code (which can make content inaccessible without JavaScript support). However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is {{em|possible}}; it is recognised that it will inevitably be {{em|inferior}}.
+
UniWiki articles should be accessible to readers using browsers and devices that have limited or no support for [[Wikipedia:JavaScript|JavaScript]] or [[Wikipedia:Cascading Style Sheets|Cascading Style Sheets]]; remember that UniWiki content can be reused freely in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognized that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is ''possible''; it is recognised that it will inevitably be ''inferior''.
  
 
To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in IE in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.
 
To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in IE in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.
  
 
== See also ==
 
== See also ==
{{Wikipedia books|Wikipedia Manual of Style}}
+
* [[Wikipedia:Wikipedia:Accessibility dos and don'ts|Wikipedia:Accessibility dos and don'ts]]
* [[Wikipedia:Accessibility dos and don'ts]] (information page summarizing the key points of this guideline)
+
* [[Wikipedia:Wikipedia:Dyslexic readers|Wikipedia:Dyslexic readers]]
* [[Usability:Accessibility Initiative]]
+
* [[Wikipedia:Wikipedia:Make technical articles understandable|Wikipedia:Make technical articles understandable]]
* [[Web Accessibility Initiative]] (WAI)
+
* [[Wikipedia:Wikipedia:Using JAWS|Wikipedia:Using JAWS]]
* [[Wikipedia:Accessibility advocates]]
 
* [[Wikipedia:Dyslexic readers]]
 
* [[Wikipedia:Make technical articles understandable]]
 
* [[Wikipedia:Using JAWS]]
 
* [[Wikipedia:WikiProject Accessibility]]
 
* [[Wikipedia:WikiProject Usability]]
 
  
 
== References ==
 
== References ==
Line 373: Line 239:
 
=== Specific ===
 
=== Specific ===
 
{{Reflist}}
 
{{Reflist}}
 
=== General ===
 
* {{cite book
 
  | first = Joe
 
  | last = Clark
 
  | year = 2003
 
  | month =
 
  | title = Building Accessible Websites
 
  | edition =
 
  | publisher = New Riders Press
 
  | location =
 
  | id = ISBN 0-7357-1150-X
 
  | url = http://www.joeclark.org/book/
 
  | accessdate = 1 January 2011
 
  }}
 
* {{cite web
 
  | first = Mark
 
  | last = Pilgrim
 
  | title = Dive Into Accessibility: 30 days to a more accessible web site
 
  | year = 2002
 
  | accessdate = 26 December 2013
 
  | url = http://diveintoaccessibility.info
 
  }}
 
 
=== Technical ===
 
{{Reflist|group="WCAG-TECH"}}
 
  
 
== External links ==
 
== External links ==
Line 404: Line 244:
 
* [http://colorfilter.wickline.org/ Colorblind web page filter]
 
* [http://colorfilter.wickline.org/ Colorblind web page filter]
 
* [http://www.w3.org/WAI/intro/components.php Essential Components of Web Accessibility], from WAI
 
* [http://www.w3.org/WAI/intro/components.php Essential Components of Web Accessibility], from WAI
* [http://www.w3.org/WAI/intro/accessibility.php Introduction to Web Accessibility], from [[Web Accessibility Initiative|WAI]]
+
* [http://www.w3.org/WAI/intro/accessibility.php Introduction to Web Accessibility], from [[Wikipedia:Web Accessibility Initiative|WAI]]
 
* [https://bugzilla.wikipedia.org/show_bug.cgi?id=367 MediaWiki bug 367: Markup accessibility issues (tracking)]
 
* [https://bugzilla.wikipedia.org/show_bug.cgi?id=367 MediaWiki bug 367: Markup accessibility issues (tracking)]
 
[[Category:UniWiki Manual of Style]]
 

Latest revision as of 18:38, 20 September 2024

This page is a part of the UniWiki's Manual of Style. It is a general guideline intended to harmonize article style across the UniWiki, though it is best treated with common sense, and exceptions may apply. Any substantive edit to this page should be approved by the Wiki Manager. When in doubt, discuss first on the talk page.

Web accessibility is the goal of making web pages easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers. The following suggestions are based on the Web Content Accessibility Guidelines 2.0 (a.k.a. ISO/IEC 40500:2012). Articles adhering to them are easier to read and edit for everyone.

Article structure

A standardized structure of articles improves accessibility, because it enables users to expect contents to be in a specific part of the page. For example, a blind user is searching for disambiguation links. If he doesn't find any at the top of the page, he will know that there aren't any and he doesn't have to read the whole page to find that out.

The guidelines to follow are UniWiki:Manual of Style/Layout and UniWiki:Manual of Style/Lead section#Elements of the lead.

Headings

Headings should be descriptive and in a consistent order.

Headings should be nested sequentially, starting with level 1 (=) or level 2 (==), then level 3 (===) and so on. Avoid skipping parts of the sequence, such as selecting levels for emphasis; this is not the purpose of headings. The exception to this guideline is when multiple level 2 heading in sequence would unnecessarily break up the page, such as the presence of several short sections in a row.

Do not make pseudo-headings using semicolon markup and try to avoid using bold markup. Screen readers and other machines can only use correctly formatted headings for navigation.

Resolution

UniWiki articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 1024×768; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally.

Text

See also: UniWiki:Manual of Style/Text formatting

In articles, do not use strikethrough to remove objectionable text. Either comment it out with "<!--" and "-->" or remove it entirely. By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) or even semantic text attributes (emphasis, importance, text deletion), so struck-out text is read normally along with any other text.

Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.

Do not use unpronounceable symbols such as ♥ (a heart symbol).

Reduced font sizes should be used sparingly. Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. In no case should the resulting font size drop below 85% of the page fontsize (or 11px).

Links

  1. Create good link descriptions, especially for external links (avoid "click here!", "this").
  2. Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" can not be reproduced into useful text by a screen reader, and will usually be read as a question mark.

Color

See also: Wikipedia:Using colors, UniWiki:Manual of Style/Text formatting#Color

Colors are most commonly found in UniWiki articles within templates and tables. For technical assistance on how colors are used, see Wikipedia:Using colors.

Articles (and other pages) that use color should keep accessibility in mind, as follows:

  • Ensure that color is not the only method used to convey important information. Especially, do not use colored text or background unless its status is also indicated using another method such as an accessible symbol matched to a legend, or footnote labels. Otherwise, blind users or readers accessing the UniWiki through a printout or device without a color screen will not receive that information.
  • Links should clearly be identifiable as a link to our readers.
  • Some readers of Wikipedia are partially or fully color-blind. Ensure the contrast of the text with its background reaches at least WCAG 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)"). Here is a selection of tools that can be used to check that the contrast is correct:
    • The Color Contrast Analyser enables you to pick colors on the page, and review their contrast thoroughly. However, be sure to only use the up-to-date "luminosity" algorithm, and not the "color brightness/difference" which is outdated.
    • You can also use Snook's color contrast tool, which is entirely up-to-date.
    • Several other tools exist on the web, but check if they are up-to-date before using them. Several tools are based on WCAG 1.0's algorithm, while the reference is now WCAG 2.0's algorithm. If the tool doesn't specifically mention that it is based on WCAG 2.0, assume that it is outdated.
  • Additional tools can be used to help produce graphical charts and color schemes for maps and the like. These tools are not accurate means to review contrast accessibility, but they can be helpful for specific tasks.

Block elements

Lists

See also: Wikipedia:Lists

Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a description list (a list made with a leading colon) or an unordered list. These excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding lists starting at the highest level.

For example, in a discussion, do this best practice:

* Support.  I like this idea.  [[User:Example]] 
** Question:  What do you like about it?  [[User:Example 2]]

or this acceptable practice:

* Support.  I like this idea.  [[User:Example]] 
*: Question:  What do you like about it?  [[User:Example 2]] 

but don't do this:

* Support.  I like this idea.  [[User:Example]] 
:: Question:  What do you like about it?  [[User:Example 2]] 

or this:

* Support.  I like this idea.  [[User:Example]]

** Question:  What do you like about it?  [[User:Example 2]]

Indentation

See also Wikipedia:Indentation

Colons (:) at the start of a line mark that line as part of an HTML definition list. The visual effect in most web browsers is to indent the line. This is used, for example, to indicate replies in a threaded discussion on Talk pages. This is not ideal for accessibility or semantics, but is currently in wide use. Blank lines should not be placed between indented lines of text, as they are interpreted by the software as marking the end of a list and the start of a new one. If a blank line is needed, place the same number of colons on it as those preceding the text below the blank line, for instance:

: Text here.
::
:: More text.

Bulleted vertical lists

For bulleted vertical lists, do not separate items by leaving blank lines between them. If list items are separated by more than one line break, the HTML list will be ended before the line break, and another HTML list will be opened after the line break. This effectively breaks what is seen as one list into several smaller lists for those using screen readers. For example, for the coding:

* White rose
* Yellow rose

* Pink rose

* Red rose

the software partially suppresses line spaces and therefore it looks like this:

  • White rose
  • Yellow rose
  • Pink rose
  • Red rose

but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end."

Do not separate list items with line breaks (<br>).

Tables

Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within them.

Use the correct wikitable pipe syntax to take advantage of all the features available. See MetaWiki:Tables for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background colour).

Many navboxes, series templates, and infoboxes are made using tables.

Avoid using <br /> tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row.

Data tables

See also: Wikipedia:Data tables tutorial
{|
|+ [caption text]
|-
! scope="col" | [column header 1]
! scope="col" | [column header 2]
! scope="col" | [column header 3]
|-
! scope="row" | [row header 1]
| [normal cell 1,2] || [normal cell 1,3]
|-
! scope="row" | [row header 2]
| [normal cell 2,2] || [normal cell 2,3]
...
|}
Caption ( |+ )
A caption is a table's title, describing its nature.
Row & column headers ( ! )
Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.
Scope of headers ( ! scope="col" | and ! scope="row" | )
This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.

Wikipedia's data tables tutorial provides detailed requirements about:

  1. Correct table captions
  2. Correct headers structure
  3. Images and color
  4. Avoiding nested tables

Layout tables

Avoid using tables for layout purposes only. The best option is to use HTML's <div> blocks and style attributes because they provide flexibility.

For simple layouts, tables can be an option. Especially if the only point of the table is to get a floating effect, then align="right" etc. will work with some browsers not supporting CSS at all. This is in fact a verbose approximation of <div> plus CSS, and not the design sin known as (nested) "table layout".

However, to avoid accessibility barriers, when using tables for layout purposes, set a role="presentation" attribute, and do not use any caption, row, or column headers, and also no summary attribute. These structural table elements should be used only for data tables. Do not use structural elements for presentation purposes, use style sheets. For Wiki table markup this means to avoid "!" (= <th> in XHTML) in such cases:

{| class="toccolours" style="width:94%" role="presentation"
| style="text-align: center; background-color: #ccf;" | '''Title'''
|-
| [normal cell] || [normal cell]
|-
| [normal cell] || [normal cell]
|}

Images

Further information: Wikipedia:Alternative text for images, UniWiki:Manual of Style#Images, Wikipedia:Image use policy#Size
  1. Images should include an alt attribute that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added it should be succinct, or should refer the reader to the caption or adjacent text: see Wikipedia:Alternative text for imates for more information.
  2. In most cases, images should contain a caption using the built in image syntax. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
  3. Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
  4. Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
  5. Images should be inside the section they belong to (after the heading and after any links to other articles), and not at the end of the previous section, otherwise screen readers would read the image (and its textual alternative) in a different section; as they would appear to viewers of the mobile site. See Wikipedia:Picture tutorial for more information.
  6. Avoid referring to images as being on the left or right. Image placement is different for viewers of the mobile version of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images.

Animations, videos and audio

Further information: Wikipedia:Media help, Wikipedia:Creation and usage of media files

Animations

To be accessible, an animation (GIF – Graphics Interchange Format) should either:

  • Not exceed a duration of five seconds (which results in making it a purely decorative element), or
  • Be equipped with control functions (stop, pause, play)

This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial converting animated GIFs to Theora OGG).

In addition, animations must not produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.

Video

Subtitles can be added to video, in Timed Text format. There is a corresponding help page at WikiMedia Commons:Video#Subtitles and closed captioning. Subtitles are meant for the transcription of speech.

There is a need for Wikipedia:Closed captions:closed captions for the hearing impaired. As of December 2016 this is not possible, but this feature could be added in the future. Closed captions are meant to be viewed instead of subtitles. Closed captions provide a text version of all important information provided through the sound. It can include dialogue, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics. Off-UniWiki guides should be consulted for how to create closed captions.[1]

A text version of the video would also be needed for the blind, but as of December 2016 there is no convenient way to provide alt text for videos.

Audio

Subtitles for speech, lyrics, dialogue, etc. can easily be added to audio files. The method is similar to that of the video: WikiMedia Commons:Video#Subtitles and closed captioning.

Styles and markup options

Best practice: Use Wikimarkup and CSS classes in preference to alternatives

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. It allows users with very specific needs to change the color schemes in their browser's style sheet. For example, a style sheet at Wikipedia:Style sheets for visually impaired users provides higher contrast backgrounds for navboxes. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose his/her own theme.

It also creates a greater degree of professionalism by ensuring a consistent appearance between articles and conformance to a style guide.

Regarding accessibility, deviations from standard conventions may be tolerated so long as they are accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough color contrast. For instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour scheme, to tie in with the dominant colour in the series. In this case, blue links on yellow provides enough colour contrast, and thus is accessible.

In general, articles should use Wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style elements <i> and <b> to format text; it is preferable to use Wiki-markup '' or ''' for purely typographic italicisation and boldfacing, respectively, and use semantic markup templates or elements for more meaningful differences. The <font> element should also be avoided in article text to emphasise logical differences, not just visual ones.. Of course there are natural exceptions; e.g., it may be beneficial to use the <u>...</u> element to indicate something like an example link that isn't really clickable, but underlining is otherwise generally not used in article text.

Users with limited CSS or JavaScript support

See also: UniWiki:Manual of Style#Scrolling lists and collapsible content

UniWiki articles should be accessible to readers using browsers and devices that have limited or no support for JavaScript or Cascading Style Sheets; remember that UniWiki content can be reused freely in ways we cannot predict as well as accessed directly via older browsers. At the same time, it is recognized that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features that would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior.

To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in IE in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

See also

References

Specific

External links