Embedding Semantic MediaWiki: Techniques for Enhanced Accessibility

Semantic MediaWiki's data is only as valuable as its visibility. The annotation layer is rarely interesting to readers — the factbox, inline queries and structured tables are what turn semantics into a better reading experience. This article covers the presentation layer of SMW: factbox configuration, queries embedded in the page design, and accessibility considerations that the default output ignores. (Installation and the annotation patterns are in the companion guides on this blog.)

1. The factbox: make data visible

$smwgShowFactbox = true;        // show on content pages
$smwgShowFactboxEdit = false;   // also on edit/preview

The factbox lists a page's properties at the bottom. For record-style pages (books, products, people) it doubles as a data table without any templates. The presentation is controlled via SMW's interfaces: you can rearrange or restyle the factbox on display via CSS targeting its output classes, or suppress it per page with __NOFACTBOX__ where the boxes would be noise.

2. Inline queries embedded in content

The pattern that makes data live in the reading flow — a 'related records' section in an article:

== Other books by this author ==
{{#ask: [[Category:Books]] [[Has author::{{FULLPAGENAME}}]]
 |?Has publication year
 |format=ul
 |limit=5
}}

Inline list formats (ul, ol, template) keep the result embedded; the template format renders each row through a template for complete layout control. Page-embedded queries are the difference between 'a wiki with tags' and 'a wiki that assembles itself'.

3. Tables: format=table and accessibility

{{#ask: [[Category:Products]] [[Status::active]]
 |?Has price
 |format=table
 |class=sortable wikitable
 |headers=plain
 |searchlabel=More products…
}}

The default table output is plain HTML — readable by screen readers, but the details matter:

• Headers — headers=plain produces <th> with proper scope attributes in recent SMW versions, so screen readers announce columns correctly
• Sortability — the sortable class gives clientside sorting for sighted users without server round-trips
• Captions — wrap queries in a <figure role="group"> with <figcaption>, or add a caption parameter where the format supports it, so the table's purpose precedes its data
• Pagination — limit= + searchlabel= keeps big result sets navigable instead of dumping 500 rows on one page

4. Result formats as navigation

• format=category — alphabetical grouping, good for glossaries and indexes
• format=timeline/timeline — chronologies from date properties
• format=map (Semantic) Result Formats + coordinates — 'near me' navigation
• format=template — the escape hatch: complete control over each result's markup, which is also the accessibility answer when table formats are not enough

5. Performance and the interface budget

Every query on a page is a query against the store:

• Keep page-embedded queries short (limit=5-class output); large reports belong on dedicated report pages
• Enable query result caching (default on) and set $smwgQueryResultCacheLifetime for hot pages
• SMW has no built-in full-text integration with results — pair it with CirrusSearch for the search side; SMW serves structure, search serves prose

The presentation layer decides whether organizational semantics feel like magic or like a maintenance chore. Factbox for record pages, one inline query per purposeful section, accessible tables for reports — that combination keeps SMW visible and the wiki readable. The SMW documentation details every result format.