دسترسی به وب هدف آسان‌تر کردن صفحات وب برای پیمایش و خواندن است. در حالی که این در درجه اول برای کمک به افراد دارای معلولیت در نظر گرفته شده است ، می تواند برای همه خوانندگان مفید باشد. هدف ما پیروی از دستورالعمل‌های دسترسی به محتوای وب 2.1، [a] است که پیشنهادات زیر بر اساس آن است. خواندن و ویرایش صفحاتی که به آنها چسبیده اند برای همه آسان تر است.
ساختار استاندارد مقالات دسترسی را بهبود می بخشد، زیرا کاربران را قادر می سازد انتظار داشته باشند که محتوا در قسمت خاصی از صفحه باشد. به عنوان مثال، اگر یک کاربر نابینا در حال جستجوی پیوندهای ابهام‌زدایی باشد و هیچ پیوندی را در بالای صفحه پیدا نکند، می‌داند که هیچ لینکی وجود ندارد و برای یافتن آن لازم نیست کل صفحه را بخواند.
استانداردسازی در حال حاضر در ویکی‌پدیا یک عادت است، بنابراین دستورالعمل‌هایی که باید دنبال شوند به سادگی Wikipedia:Manual of Style/Layout و Wikipedia:Manual of Style/Lead بخش § Elements هستند .
سرفصل ها باید توصیفی و به ترتیبی ثابت باشند که در کتابچه راهنمای سبک تعریف شده است .
عناوین را به صورت متوالی قرار دهید، از سطح 2 ( ==) شروع کنید، سپس سطح 3 ( ===) و غیره. (سطح 1 عنوان صفحه است که به طور خودکار ایجاد می شود.) از قسمت هایی از دنباله، مانند انتخاب سطوح برای تاکید، صرفنظر نکنید. این هدف سرفصل ها نیست.
به منظور خوانایی برای ویرایشگران با دید ضعیف - فقط در ویرایشگر منبع - ممکن است یک خط خالی در زیر هر عنوان اضافه شود، اما نه بیشتر از یک. بیش از یک خط خالی در زیر عنوان بخش باعث می شود فضای اضافی در صفحه رندر شده قابل مشاهده باشد. همچنین باید در نظر گرفته شود که چگونه یک خط سفید خالی در زیر عنوان بخش ممکن است در یک صفحه کوچک برای یک مقاله خاص ظاهر شود، زیرا بسیاری از ویراستاران از دستگاه های تلفن همراه برای ویرایش استفاده می کنند و وجود یک خط خالی در زیر عنوان ممکن است در واقع خوانایی را کاهش دهد. برای این ویراستاران، برای برخی مقالات.
با سوء استفاده از نشانه گذاری نقطه ویرگول (محصول برای لیست های توضیحات ) عناوین کاذب ایجاد نکنید و سعی کنید از نشانه گذاری پررنگ خودداری کنید. صفحه‌خوان‌ها و سایر فناوری‌های کمکی فقط می‌توانند از سرفصل‌هایی استفاده کنند که دارای نشانه‌گذاری عنوان برای پیمایش هستند. اگر می خواهید اندازه فهرست مطالب (TOC) را کاهش دهید، به جای آن از {{ TOC limit }} استفاده کنید . در مواردی که {{ محدودیت TOC }} به دلیل عناوین سطح پایین‌تر در جای دیگر مقاله قابل استفاده نباشد، استفاده از bold برای زیر عنوان‌های فرعی کمترین مزاحمت را برای کاربران صفحه‌خوان ایجاد می‌کند. استفاده از یک عنوان شبه به این معنی است که شما تمام گزینه های دیگر را تمام کرده اید. منظور از آن نادر است.
در ویکی کد، عناصر شناور (از جمله تصاویر) باید در قسمتی که به آن تعلق دارند قرار گیرند. تصویر را در انتهای بخش قبلی قرار ندهید. (بسته به پلتفرم، «انباشتن» چندین تصویر در کنار مقدار نسبتاً کمی متن ممکن است باعث شود یک تصویر خاص به بخش بعدی منتقل شود. با این حال، این یک مشکل دسترسی نیست، زیرا خوانندگان صفحه همیشه هر تصویر را alt=در خارج می‌خوانند. نقطه ای که تصویر کدگذاری شده است ).
مقالات ویکی‌پدیا باید برای خوانندگانی که از دستگاه‌هایی با صفحه‌نمایش کوچک مانند دستگاه‌های تلفن همراه استفاده می‌کنند ، یا برای خوانندگانی که از نمایشگرهایی با وضوح پایین استفاده می‌کنند، در دسترس باشد. در دسکتاپ، گاهی اوقات این مشکل در مقالاتی با چندین تصویر در دو طرف صفحه نمایش وجود دارد . اگرچه رزولوشن‌های پایین‌تر تمایل دارند پاراگراف‌ها را به صورت عمودی کشیده شوند، اما تصاویر را در آن جهت از هم جدا می‌کنند، مراقب باشید تصاویر یا محتوای شناور دیگر را همزمان در دو طرف صفحه اضافه نکنید. جداول و تصاویر بزرگ نیز می توانند مشکلاتی ایجاد کنند. گاهی اوقات پیمایش افقی اجتناب ناپذیر است، اما تغییر ساختار جداول گسترده را در نظر بگیرید تا به جای افقی، به صورت عمودی گسترش یابند.
به طور پیش‌فرض، اکثر صفحه‌خوان‌ها ویژگی‌های متن نمایشی (پررنگ، مورب، زیرخط، تک‌فضا، خط خطی) یا حتی ویژگی‌های متن معنایی (تاکید، اهمیت، حذف متن) را نشان نمی‌دهند، بنابراین متن خط‌دار به طور معمول همراه با هر متن دیگری خوانده می‌شود. (ویراستارانی که از صفحه‌خوان‌های صفحه‌خوان استفاده می‌کنند و در بحث‌های خط‌مشی و حذف ویکی‌پدیا شرکت می‌کنند، توصیه می‌شود هنگام انجام این کار، اعلان‌های مربوط به ویژگی‌های متن را روشن کنند، زیرا متن ضربه‌خورده در بحث‌های داخلی ویکی‌پدیا بسیار رایج است.)
از آنجایی که خط خطی معمولاً توسط صفحه‌خوان‌ها نادیده گرفته می‌شود، استفاده نادر از آن در مقاله‌ها (مثلاً برای نشان دادن تغییرات در تجزیه و تحلیل نوشتاری) اگر تنها نشانه استفاده‌شده باشد، باعث مشکلات دسترسی و سردرگمی آشکار می‌شود. این هم برای عناصر <s>و <del>(همراه با متناظر آنها <ins>که معمولاً به صورت بصری به صورت زیرخط دار ارائه می شوند) و هم برای الگوهایی که از آنها استفاده می کنند، صدق می کند. از خط خطی برای اعتراض به محتوایی که فکر می کنید نامناسب یا نادرست است استفاده نکنید. در عوض، آن را با <!--و نظر دهید -->، آن را به طور کامل حذف کنید، یا از یک الگوی پاکسازی/اختلاف درون خطی استفاده کنید و موضوع را در صفحه بحث مطرح کنید.
صفحه‌خوان‌ها پشتیبانی بسیار متفاوتی از کاراکترهای خارج از Latin-1 و Windows-1252 دارند و نمی‌توان فرض کرد که هر یک از کاراکترهای معین در این محدوده‌ها چگونه تلفظ می‌شوند. اگر صفحه‌خوان یا ترکیب‌کننده گفتار آنها را تشخیص ندهد، ممکن است به‌عنوان علامت سؤال تلفظ شوند یا به طور کامل از خروجی گفتار حذف شوند.
توالی کاراکترها باید برای انتقال جنبه های معنایی متن (و ترجیحاً سایر اشکال مشابه محتوا) کافی باشد. اتکا به "نمادهای ویژه" سفارشی که فقط با ویژگی های CSS یا نشانه گذاری ویکی قابل تشخیص هستند قابل قبول نیست.
از تکنیک هایی که نیاز به تعامل برای ارائه اطلاعات دارند، مانند راهنمای ابزار یا هر متن دیگری که «هواست» است، استفاده نکنید. اختصارات از این الزامات مستثنی هستند، بنابراین الگو (یک پوشش برای عنصر) ممکن است برای نشان دادن شکل طولانی یک مخفف (از جمله مخفف یا اولیه) استفاده شود.{{abbr}}<abbr>
خطوط شکسته را در یک جمله وارد نکنید، زیرا این کار ویرایش با صفحه‌خوان را سخت‌تر می‌کند . یک شکست خط ممکن است به دنبال یک جمله باشد که ممکن است به برخی از ویرایشگران کمک کند.
اندازه فونت های کوچک یا بزرگ شده باید به قدری استفاده شوند و معمولاً با عناصر صفحه خودکار مانند سرفصل ها، سرصفحه های جدول و قالب های استاندارد انجام می شوند. تغییرات اندازه به صورت درصدی از اندازه فونت اصلی و نه به عنوان اندازه مطلق در پیکسل یا اندازه نقطه مشخص می شود. اندازه های نسبی با اجازه دادن به آنها برای تنظیم اندازه فونت بزرگ (r) پیش فرض در تنظیمات مرورگر، دسترسی را برای کاربران کم بینا افزایش می دهد. اندازه های مطلق چنین قابلیتی را از کاربران سلب می کنند.
از استفاده از اندازه‌های قلم کوچکتر در عناصر صفحه که قبلاً از اندازه قلم کوچک‌تری استفاده می‌کنند، مانند اکثر متن‌های داخل جعبه‌های اطلاعات ، جعبه‌های ناوبری و بخش‌های مراجع خودداری کنید . [b] این بدان معناست که <small>...</small>برچسب‌ها و الگوهایی مانند و نباید روی متن ساده در آن عناصر اعمال شوند. در هیچ موردی نباید اندازه فونت حاصل از هر متنی کمتر از 85% اندازه فونت پیش‌فرض صفحه باشد. توجه داشته باشید که تگ HTML معنای معنایی چاپ دقیق یا نظرات جانبی دارد. [2] از آن برای تغییرات سبکی استفاده نکنید.{{small}}{{smalldiv}}<small>...</small>
به غیر از استثناهایی که در WP:Manual of Style/Dates و اعداد توضیح داده شده است § کسرها ، از کاراکترهای کسری از پیش ترکیب شده مانند ½ (نشانه گذاری منسوخ شده: ½یا ) استفاده نکنید ½. این به این دلیل است که برخی از کسرهای از پیش ساخته شده ممکن است با صفحه‌خوان‌ها کار نکنند یا برای خوانندگانی که بینایی ضعیفی دارند، رمزگشایی غیرمنطقی دشوار باشد. استفاده ای که کسرهایی به شکل 3 ⁄ 4 تولید می کند . (برای متن علمی و ریاضی ، از آن استفاده کنید که کسری را به شکل تولید می کند{{Fraction}}{{sfrac}}3/4. )
به‌طور پیش‌فرض، مقاله‌های ویکی‌پدیای انگلیسی به صراحت به مرورگر اعلام می‌کنند که کاملاً به زبان انگلیسی نوشته شده‌اند. متنی به زبانی غیر از انگلیسی باید به این صورت برچسب گذاری شود، معمولاً با الگویی مانند (یا یکی از مشتقات آن). این متن را در یک برچسب زبان IETF می پیچد که زبان و اسکریپت را مشخص می کند. به عنوان مثال:{{lang}}
''Assemblée nationale''صرفاً مورب است و مشخص نکرده است که متنی به زبان فرانسوی است. اکثر صفحه‌خوان‌هایی که سعی می‌کنند این کار را انجام دهند، مضحک یا گیج‌کننده به نظر می‌رسند.
{{lang|fr|Assemblée nationale}}به عنوان Assemblée nationale ارائه می شود که به طور پیش فرض مورب است و به خوانندگان صفحه امکان می دهد صدای فرانسوی زبان را انتخاب کنند. {{langx|fr|Assemblée nationale}}→ فرانسوی : Assemblée nationale – این شبیه به موارد فوق است.منطق : در میان کاربردهای دیگر، مشخص کردن زبان متن به {{lang}}سینت سایزرهای گفتار اجازه می دهد صدایی را انتخاب کنند که قادر به خواندن صحیح متن باشد. [3]
برچسب های زبان IETF زبان متن را مطابق با مشخصات ISO 639 مشخص می کنند ، اما همچنین از کدام اسکریپت برای نوشتن زبان استفاده می شود:
{{lang|sr-Cyrl|Народна скупштина}}→ Народна скупштина {{lang|sr-Latn|Narodna skupština}}← Narodna skupština – صربی را می توان با استفاده از خط لاتین یا سیریلیک نوشت. {{lang|ja|Kokumin gikai}}– به‌طور پیش‌فرض، انتظار می‌رود که متن ژاپنی با استفاده از سیستم نوشتاری بومی نوشته شود، که قوانین آن ممکن است با برخی از کاراکترها متفاوت رفتار کند. {{lang|ja-Latn|Kokumin gikai}}ژاپنی را مشخص می کند که با الفبای لاتین نوشته شده است (مثلا rōmaji ). {{transliteration|ja|Kokumin gikai}}معادل موارد فوق می باشد.بدون تعیین یک اسکریپت، تگ های IETF رایج ترین اسکریپت مورد استفاده برای نوشتن یک زبان خاص را فرض می کنند. بنابراین، نویسه‌گردانی باید استفاده از خط لاتین را با الحاق -Latnبه کد زبان یا با استفاده از الگوی معادل مشخص کند. ویکی‌پدیا دارای تعدادی الگوی خاص زبان مانند و است که قابلیت‌های خاص زبان را در اختیار ویرایشگران قرار می‌دهد، مانند توانایی نمایش آسان چندین نویسه‌گردانی با یک الگو. هر زبانی الگوی مخصوص به خود را ندارد، اما استفاده از یکی ممکن است برای ساده‌سازی متن ویکی‌تست مفید باشد، به‌جای اینکه پاراگراف‌ها را با نمونه‌هایی از و .{{transliteration}}{{lang-zh}}{{nihongo}}{{lang}}{{transliteration}}
معمولاً علاوه بر یا الگوها، که متن را با استفاده از الفبای لاتین به صورت پیش‌فرض مورب می‌کشند، نیازی نیست. اگر متن نباید مورب باشد، مانند نام مکان‌ها یا افراد، ممکن است پارامتر اضافه شود. [c] همانطور که در MOS:NON-ENG مشخص شده است ، متنی که از خط غیر لاتین استفاده می‌کند تقریباً هرگز نباید مورب یا پررنگ باشد.{{lang}}{{[[Template:lang-xx|lang-xx]]}}|italic=unset
رونویسی های آوایی یا راهنمای تلفظ باید از , یا الگوی مناسب دیگری استفاده کنند. برای پروتو-هند و اروپایی استفاده می شود .{{IPA}}{{respell}}{{PIE}}
رنگ ها بیشتر در مقالات ویکی پدیا در قالب ها و جداول یافت می شوند .
مقالات (و سایر صفحات) که از رنگ استفاده می کنند باید دسترسی را به شرح زیر در نظر داشته باشند:
موارد لیست را با گذاشتن خطوط خالی یا شکستن ستون های جدولی بین آنها جدا نکنید. این شامل موارد موجود در لیست توضیحات (لیستی که با نقطه ویرگول یا دونقطه اصلی ساخته شده است، که اغلب بحث‌های صفحه بحث نیز به این شکل قالب‌بندی می‌شوند) یا فهرست مرتب شده یا فهرست نامرتب . فهرست ها برای گروه بندی عناصری هستند که به هم تعلق دارند، اما مدیاویکی خط خالی را به عنوان انتهای یک لیست تفسیر می کند و یک لیست جدید را شروع می کند. شکسته شدن بیش از حد دو خط نیز باعث اختلال در صفحه خوان ها می شود ، که در زمانی که تنها یک لیست در نظر گرفته شده بود، لیست های متعددی را اعلام می کند و بنابراین ممکن است کاربران این برنامه ها را گمراه یا گیج کند. چنین قالب بندی نامناسبی همچنین می تواند مدت زمان خواندن لیست را بیش از سه برابر کند.
به همین ترتیب، بین انواع نشانگرهای فهرست اولیه (دونقطه، ستاره یا علائم هش) در یک لیست جابجا نشوید. هنگام تورفتگی در پاسخ به پستی که با هر ترکیبی از دو نقطه و ستاره و گاهی اوقات نشانه های هش شروع می شود، لازم است هر سری از آن کاراکترها را که در بالا استفاده شده است کپی کنید و یک کاراکتر دیگر از این قبیل را اضافه کنید. متناوبا، به سادگی بیرون زده و یک بحث جدید (یعنی یک لیست HTML جدید) شروع کنید.
مثال ها:
در یک بحث، این کار را انجام دهید،
* پشتیبانی من این ایده را دوست دارم. —کاربر: مثال ** سوال: چه چیزی را در مورد آن دوست دارید؟ —کاربر:Example2 *** به نظر می رسد که با روح ویکی پدیا مطابقت دارد. — کاربر: مثالیا، در یک بحث بدون گلوله، این،
: پشتیبانی من این ایده را دوست دارم. —User:Example :: سوال: چه چیزی را در مورد آن دوست دارید؟ —User:Example2 ::: به نظر می رسد که با روح ویکی پدیا مطابقت دارد. — کاربر: مثالسرکوب گلوله در پاسخ نیز قابل قبول است،
* پشتیبانی من این ایده را دوست دارم. —کاربر: مثال *: سؤال: چه چیزی را در مورد آن دوست دارید؟ —User:Example2 *:: به نظر می رسد که با روح ویکی پدیا مطابقت دارد. — کاربر: مثال
اما نوع را از لیست گلوله به لیست توضیحات تغییر ندهید،
* پشتیبانی من این ایده را دوست دارم. —User:Example :: سوال: چه چیزی را در مورد آن دوست دارید؟ — کاربر: مثال 2و نه تغییر از لیست گلوله به نوع ترکیبی،
* پشتیبانی من این ایده را دوست دارم. —کاربر: مثال :* سوال: چه چیزی را در مورد آن دوست دارید؟ — کاربر: مثال 2خالی گذاشتن خطوط بین آیتم های فهرست معمولاً عمل بدی است،
* پشتیبانی من این ایده را دوست دارم. — کاربر: مثال** سوال: چه چیزی را در آن دوست دارید؟ — کاربر: مثال 2همانطور که پریدن بیش از یک سطح است،
* پشتیبانی من این ایده را دوست دارم. —کاربر: مثال *** سوال: چه چیزی را در مورد آن دوست دارید؟ — کاربر: مثال 2
این به طور کلی دلسرد می شود:
: پشتیبانی من این ایده را دوست دارم. —کاربر: مثال :* سوال: چه چیزی را در مورد آن دوست دارید؟ — کاربر: مثال 2این تزریق یک گلوله به طور غیرضروری به پیچیدگی لیست می افزاید و باعث می شود افراد بیشتر از سطوح تورفتگی اشتباه در پاسخ ها استفاده کنند.
متأسفانه نشانه‌گذاری فهرست معمولی مدیاویکی با نشانه‌گذاری پاراگراف معمولی مدیاویکی ناسازگار است.
برای قرار دادن چند پاراگراف در یک آیتم فهرست، آنها را با :{{pb}}
* این یک مورد است. {{ pb }} این پاراگراف دیگری در این مورد است. * این یک مورد دیگر است.این را می توان با نشانه گذاری صریح HTML برای پاراگراف ها نیز انجام داد (به تگ پایانی توجه کنید </p>):
* این یک مورد است. < p > این پاراگراف دیگری در این مورد است. </ p > * این مورد دیگری است.در هر دو مورد، این باید در یک خط کد انجام شود. با این حال، می‌توانید به صورت اختیاری از ترفند قرار دادن یک شکست خط کد در یک نظر HTML (که آن را به عنوان شکست خط خروجی سرکوب می‌کند) برای جداسازی بهتر پاراگراف‌ها در نمای کد استفاده کنید:
* این یک مورد است. <!-- --> < p > این پاراگراف دیگری در این مورد است. </ p > * این مورد دیگری است.این تکنیک را می توان برای اشکال مختلف گنجاندن بلوک در یک آیتم لیست استفاده کرد (زیرا آیتم های لیست از نظر فنی عناصر بلوکی هستند که می توانند شامل عناصر بلوک دیگری باشند):
* این یک مورد است. <!-- --> < p > این پاراگراف دیگری در این مورد است، و ما قصد داریم از کسی نقل قول کنیم: </ p > <!-- --> {{ بلوک نقل قول بحث | دنیایی را تصور کنید که در آن به تک تک افراد روی کره زمین دسترسی رایگان به مجموع دانش بشری داده می شود. | Jimbo }} <!-- --> < p > این پاراگراف پایانی در همان مورد فهرست است. </ p > * این مورد دیگری است.توجه داشته باشید که نمی توان از هر الگوی فانتزی به این شکل استفاده کرد (مثلاً برخی از الگوهای نقل قول تزئینی مبتنی بر جدول هستند و تجزیه کننده مدیاویکی چنین نشانه گذاری هایی را مانند قرار گرفتن در یک آیتم فهرست انجام نمی دهد).
از شکست خط برای شبیه سازی پاراگراف ها استفاده نکنید، زیرا آنها معنایی متفاوتی دارند:
* این یک مورد است. < br /> این همان پاراگراف است که قبل از آن یک خط شکسته وجود دارد. * این یک مورد دیگر است. تگ های خط شکسته برای قرار دادن در یک پاراگراف، مانند سطرهایی از یک شعر یا یک بلوک از کد منبع هستند. همچنین به تگ های مدیاویکی <poem>و مدیاویکی مراجعه کنید <syntaxhighlight>.
قطعاً سعی نکنید از کولون برای مطابقت با سطح تورفتگی استفاده کنید، زیرا (همانطور که در بالا ذکر شد) سه لیست جداگانه ایجاد می کند:
* این یک مورد است. : این یک لیست کاملا مجزا است. * این لیست سوم است.همچنین، می‌توانید از یکی از قالب‌های فهرست HTML برای تضمین گروه‌بندی استفاده کنید. این برای گنجاندن عناصر بلوک، مانند کد قالب‌بندی شده، در لیست‌ها بسیار مفید است:
{{ لیست گلوله‌ای | 1 = این یک مورد است: < pre >این یک کد است.</ pre >این هنوز همان آیتم است.| 2 = این مورد دوم است. }}اما این تکنیک در صفحات بحث استفاده نمی شود.
یک رویکرد قابل دسترس برای تورفتگی، الگوی محتوای چند خطی است. از CSS برای تورفتگی مواد استفاده می کند . برای خطوط تک، الگوهای مختلفی وجود دارد، از جمله (الگوی جهانی، با نام یکسان در تمام سایت‌های ویکی‌مدیا). این تورفتگی با کاراکترهای مختلف فاصله سفید دارد. از عنصر یا الگوهایی که از آن استفاده می کنند (مانند ) برای تورفتگی بصری سوء استفاده نکنید . آنها فقط برای مطالب نقل شده مستقیم هستند. جایگزین عمومی برای چنین موارد غیر نقل قول ایجاد شده است، بنابراین لطفا از آن استفاده کنید.{{block indent}}{{in5}}<blockquote>...</blockquote>{{blockquote}}{{block indent}}
دو نقطه ( :) در ابتدای یک خط آن خط را در تجزیه کننده مدیاویکی به عنوان بخشی از لیست توضیحات<dd> HTML ( ) مشخص می کند. [d] جلوه بصری در اکثر مرورگرهای وب، تورفتگی خط است. برای مثال برای نشان دادن پاسخ ها در یک بحث رشته ای در صفحات بحث از این مورد استفاده می شود. با این حال، این نشانه گذاری به تنهایی عنصر (اصطلاح) مورد نیاز فهرست توضیحات را که (توضیح/تعریف) به آن مربوط می شود، ندارد . همانطور که با بررسی کد ارسال شده به مرورگر مشاهده می شود، این منجر به شکسته شدن HTML می شود (یعنی اعتبار سنجی ناموفق است [6] ). نتیجه این است که فناوری کمکی، مانند صفحه‌خوان‌ها، فهرست توصیفی را اعلام می‌کند که وجود ندارد، که برای هر بازدیدکننده‌ای که از نشانه‌گذاری شکسته ویکی‌پدیا استفاده نمی‌کند، گیج‌کننده است. این برای دسترسی، معناشناسی یا استفاده مجدد ایده‌آل نیست ، اما در حال حاضر با وجود مشکلاتی که برای کاربران صفحه‌خوان ایجاد می‌کند، معمولاً استفاده می‌شود.<dl><dt><dd>
خطوط خالی نباید بین خطوط متن دارای تورفتگی دو نقطه قرار گیرد - به خصوص در محتوای مقاله. این توسط نرم افزار به عنوان علامت گذاری پایان یک لیست و شروع یک لیست جدید تفسیر می شود.
در صورت نیاز به فضا، دو رویکرد وجود دارد که نتایج متفاوتی برای صفحه‌خوان‌ها خواهد داشت:
اولین مورد این است که یک خط خالی با همان تعداد دو نقطه روی آن اضافه کنید که قبل از متن بالا و پایین خط خالی است. این زمانی مناسب است که دو ویراستار بلافاصله پس از هم در یک سطح تورفتگی نظراتی را بیان می کنند. به عنوان مثال:
: کاملا موافقم — کاربر: مثال:: من متقاعد نشده ام. آیا منبع بهتری در دسترس است؟ – کاربر: مثال 2
این به خواننده صفحه نمایش می گوید که این دو مورد از لیست است (یکی خالی نادیده گرفته می شود).
رویکرد دوم، برای زمانی که قرار است مطالب یک نظر واحد باشد (یا سایر موارد فهرست، به عنوان مثال در متن مقاله) استفاده از نشانه گذاری پاراگراف جدید در همان خط خروجی است (به بخش قبلی برای تکنیک های پیشرفته در این مورد مراجعه کنید تا شامل شود. بلوک های محتوای پیچیده):
: اینجا پیامک ارسال کنید.{{pb}}متن بیشتر. — کاربر: مثال 3برای نمایش یک فرمول یا عبارت ریاضی در خط خودش، توصیه می شود به <math display="block">1 + 1 = 2</math>جای :<math>1 + 1 = 2</math>.
برای لیست های عمودی گلوله ای، موارد را با گذاشتن خطوط خالی بین آنها جدا نکنید. در عوض، از الگوی {{pb}} یا نشانه‌گذاری HTML <p> استفاده کنید. (یک خط خالی قبل از شروع یک لیست، یا بعد از پایان لیست، مشکلی ایجاد نمی کند.)
مشکل خطوط خالی در وسط یک لیست این است که اگر موارد لیست با بیش از یک خط از هم جدا شوند، لیست HTML قبل از شکست خط به پایان می رسد و لیست HTML دیگری پس از شکست خط باز می شود. این به طور موثر آنچه را که به عنوان یک لیست دیده می شود به چندین لیست کوچکتر برای کسانی که از صفحه خوان ها استفاده می کنند، می شکند . به عنوان مثال، برای کدنویسی:
* گل رز سفید* گل رز زرد* گل رز صورتی* گل رز قرمز
نرم افزار تا حدی فضاهای خطوط را سرکوب می کند و بنابراین به نظر می رسد:
اما توسط یک صفحه خوان به صورت زیر خوانده می شود: "فهرست 2 مورد: (گلوله) گل رز سفید، (گلوله) گل رز زرد، انتهای لیست. لیست 1 مورد: (گلوله) گل رز صورتی، انتهای لیست. لیست 1 مورد: (گلوله) گل رز قرمز، پایان فهرست."
آیتم های لیست را با خطوط شکسته جدا نکنید ( <br />). اگر قرار است لیست عمودی بماند از / استفاده کنید . یا اگر لیست را می توان به صورت افقی (در خط) بهتر ارائه کرد، همانطور که در دو بخش زیر توضیح داده شد، در نظر بگیرید .{{plainlist}}{{unbulleted list}}{{flatlist}}{{hlist}}
برای لیست‌های بدون گلوله در حال اجرا در صفحه، الگوهای {{ لیست ساده }} و {{ لیست بدون گلوله }} در دسترس هستند تا دسترسی و معنای معنایی را با علامت‌گذاری آنچه که به وضوح یک فهرست است به‌جای گنجاندن <br />شکست‌های خط، که نباید استفاده شوند، بهبود می‌بخشد. - بالا را ببینید. آنها فقط در نشانه گذاری ویکی مورد استفاده برای ایجاد لیست تفاوت دارند. توجه داشته باشید که از آنجایی که اینها الگو هستند، متن هر آیتم فهرست نمی‌تواند حاوی نماد نوار عمودی ( ) باشد، مگر اینکه با تگ‌ها |جایگزین شود {{!}}یا در داخل آن قرار گیرد . <nowiki>...</nowiki>به طور مشابه نمی‌تواند حاوی علامت تساوی ( =) باشد، مگر اینکه با {{=}}یا موجود در آن جایگزین شود <nowiki>...</nowiki>، اگرچه می‌توانید با نام‌گذاری پارامترها ( و غیره) از آن عبور |1=کنید |2=. اگر این کار خیلی دردسرساز شد، ممکن است بتوانید به جای آن از این نوع با {{ endplainlist }} استفاده کنید . در داخل یک مرجع، ممکن است به جای آن به {{ لیست بدون گلوله citebundle }} نیاز داشته باشید .
از طرف دیگر، در قالب هایی مانند navboxes و موارد مشابه، یا هر محفظه مناسب، چنین لیست هایی ممکن است با کلاس " plainlist" استایل دهی شوند، به این ترتیب:
| listclass = plainlistیا| bodyclass = plainlistدر جعبه اطلاعات ، موارد زیر ممکن است استفاده شود:
| rowclass = plainlistیا| bodyclass = plainlistمسائل مربوط به خط خالی بالا همچنین بر لیست های شماره گذاری شده با استفاده از #نشانه گذاری تأثیر می گذارد و شماره گذاری لیست پس از شکست خط بازنشانی می شود. مشکل شکستن لیست خطوط خالی برای لیست های توصیف (تعریف، ارتباط) ، استفاده ;و :نشانه گذاری نیز صدق می کند. اگر در عوض با الگوهای واژه نامه ایجاد شود، آن نوع لیست می تواند دارای شکاف خط در آن باشد .
برای فهرست‌هایی که در سراسر صفحه اجرا می‌شوند، و در ردیف‌های منفرد در جعبه‌های اطلاعات و سایر جداول، الگوها و (برای «فهرست افقی») برای بهبود دسترسی و معنای معنایی در دسترس هستند. این ویژگی به جای استفاده از کاراکترهای گلوله‌ای که مثلاً توسط نرم‌افزار کمکی مورد استفاده مردم خوانده می‌شوند، از نشانه‌گذاری صحیح HTML برای هر آیتم فهرست استفاده می‌کند. که نابینا هستند الگوها فقط در نشانه گذاری ویکی مورد استفاده برای ایجاد لیست متفاوت هستند. توجه داشته باشید که وقتی متن به این (یا هر الگوی دیگر) ارسال می شود، کاراکتر نوار عمودی ( ) باید با .{{flatlist}}{{hlist}}|{{!}}
از طرف دیگر، در قالب هایی مانند navboxes و موارد مشابه، یا هر ظرف مناسب، چنین لیست هایی ممکن است با کلاس استایل دهی شوند hlist، به این ترتیب:
| listclass = hlistیا| bodyclass = hlistدر جعبه اطلاعات :
| rowclass = hlistیا| bodyclass = hlistممکن است استفاده شود.
استفاده نادرست از نقطه ویرگول برای پررنگ کردن «عنوان جعلی» قبل از فهرست (شکل 1) باعث ایجاد شکاف در لیست و بدتر از آن می شود. خط نقطه ویرگول یک لیست توضیحات یک موردی است، بدون محتوای توضیحات، و پس از آن یک لیست دوم وجود دارد.
در عوض، از نشانه گذاری عنوان (شکل 2) استفاده کنید.
1. نادرست
; گازهای نجیب * هلیوم * نئون * آرگون * کریپتون * زنون * رادون2. سرفصل
== گازهای نجیب == * هلیوم * نئون * آرگون * کریپتون * زنون * رادونصفحهخوانها و سایر ابزارهای مرور وب از برچسب‌های جدول خاصی برای کمک به کاربران برای حرکت در داده‌های موجود در آنها استفاده می‌کنند.
برای استفاده از تمام ویژگی های موجود، از نحو صحیح لوله ویکی قابل استفاده استفاده کنید. برای اطلاعات بیشتر در مورد نحو خاص مورد استفاده برای جداول، به mw:Help:Tables مراجعه کنید. برای ایجاد معنای معنایی (مانند تغییر رنگ پس‌زمینه) صرفاً از قالب‌بندی، چه از طریق CSS یا سبک‌های کدگذاری شده سخت استفاده نکنید.
بسیاری از ناو باکس ها ، قالب های سری و جعبه اطلاعات با استفاده از جداول ساخته می شوند.
از استفاده <br />یا <hr />برچسب‌ها در سلول‌های مجاور برای شبیه‌سازی یک ردیف بصری که در ساختار جدول HTML منعکس نمی‌شود، خودداری کنید. این مشکل برای کاربران صفحه‌خوان‌هایی است که جداول را سلول به سلول، سطر به ردیف HTML می‌خوانند، نه سطر به سطر بصری بصری.
ویکی متن:
{| class = "wikitable" |+ متن زیرنویس |- ! scope = "col" | هدر ستون 1 ! scope = "col" | هدر ستون 2 ! scope = "col" | سربرگ ستون 3 |- ! scope = "ردیف" | سرصفحه ردیف 1 | داده 1 || داده 2 |- ! scope = "ردیف" | سربرگ ردیف 2 | داده 3 || داده 4 |} تولید می کند:
|+) ! )! scope="col" |و ! scope="row" |)! scope="colgroup" colspan="2" |اگر سرصفحه ستون شامل گروهی از ستون‌ها می‌شود و ! scope="rowgroup" rowspan="2" |اگر سرصفحه یک ردیف شامل یک گروه از ردیف‌ها می‌شود، تعداد دهانه را در صورت نیاز تنظیم کنید . سرصفحه ها اکنون می توانند به سلول های مربوطه مرتبط شوند. [11]ویکی‌پدیا: راهنمای جداول سبک/دسترس‌پذیری/داده‌ها الزامات دقیقی را در مورد موارد زیر ارائه می‌کند:
از استفاده از جداول برای موقعیت یابی بصری محتوای غیر جدولی خودداری کنید. جداول داده اطلاعات اضافی و روش‌های ناوبری را ارائه می‌کنند که وقتی محتوا فاقد روابط منطقی ردیف و ستون باشد، ممکن است گیج‌کننده باشد. در عوض، از عناصر یا <div>s و ویژگی های مناسب معنایی استفاده کنید style.
هنگام استفاده از جدول برای قرار دادن محتوای غیر جدولی، به خوانندگان صفحه کمک کنید تا آن را به عنوان جدول طرح‌بندی شناسایی کنند، نه جدول داده. یک role="presentation"ویژگی روی میز تنظیم کنید و هیچ summaryویژگی را تنظیم نکنید. از هیچ <caption>یا <th>عنصری در داخل میز یا داخل هر جدول تودرتو استفاده نکنید . در نشانه گذاری جدول ویکی، به این معنی است که از پیشوند |+یا پیشوند استفاده نکنید !. مطمئن شوید که ترتیب خواندن مطالب صحیح است. جلوه های بصری، مانند وسط یا حروف برجسته را می توان با شیوه نامه ها یا عناصر معنایی به دست آورد. به عنوان مثال:
{| نقش = "ارائه" |- | colspan = "2" style = "text-align: center; background-color: #ccf;" | <strong> متن مهم </strong> | - | سریع || روباه قهوه ای |- | می پرد از روی || سگ تنبل |} 
در بیشتر موارد ، تصاویر باید شامل یک عنوان با استفاده از نحو تصویر داخلی باشند. کپشن باید به طور مختصر معنای تصویر و اطلاعات ضروری را که سعی در انتقال آن دارد، توصیف کند.
توضیحات تصویری دقیق، در مواردی که برای یک مقاله مناسب نیست، باید در صفحه توضیحات تصویر قرار داده شود، با ذکر این نکته که فعال کردن پیوند تصویر منجر به توضیحات دقیق‌تری می‌شود.
تصاویر باید در قسمتی که به آن مربوط می شود (بعد از عنوان و هر نت ) باشد و نه در خود عنوان و نه در انتهای بخش قبلی. این تضمین می‌کند که صفحه‌خوان‌ها می‌خوانند، و سایت تلفن همراه، تصویر (و جایگزین متنی آن) را در بخش صحیح نمایش می‌دهد.
این دستورالعمل شامل متن جایگزین برای معادلات با فرمت LaTeX در <math>حالت است. ویکی‌پدیا:راهنمای سبک/ریاضیات § متن جایگزین را ببینید
از درج تصاویر در عنوان خودداری کنید. این شامل آیکون ها و <math>نشانه گذاری است. انجام این کار می تواند پیوندهای بخش ها را شکسته و مشکلات دیگری ایجاد کند.
تصاویر و نمادهایی که صرفاً تزئینی نیستند باید دارای ویژگی alt باشند که به عنوان جایگزینی برای تصویر برای خوانندگان نابینا، جستجوگرها و سایر کاربران غیربصری عمل می کند. اگر متن جایگزین اضافی اضافه شود، باید مختصر باشد یا خواننده را به عنوان یا متن مجاور ارجاع دهد.
برای در دسترس بودن، یک انیمیشن ( GIF – Graphics Interchange Format) باید یا:
این مستلزم آن است که GIF هایی با انیمیشن های طولانی تر از پنج ثانیه به ویدیو تبدیل شوند (برای یادگیری نحوه، آموزش تبدیل GIF های متحرک به Theora OGG را ببینید).
علاوه بر این، انیمیشن ها نباید بیش از سه فلاش در هر دوره یک ثانیه ای تولید کنند. محتوایی که بیش از این حد چشمک می زند، باعث تشنج می شود. [14]
زیرنویس بسته (CC) و زیرنویس هر دو فرآیند نمایش متن روی فایل‌های صوتی و تصویری در ویکی‌پدیا از طریق c:Commons:Timed Text هستند. هر دو معمولاً به عنوان رونویسی از بخش صوتی یک برنامه در صورت وقوع (به کلمه یا به صورت ویرایش شده) استفاده می‌شوند، که گاهی اوقات شامل توصیف عناصر غیرگفتاری نیز می‌شود. این به افراد کم شنوا و ناشنوا کمک می کند و راهی را برای افراد غیر زبان مادری فراهم می کند تا محتوای یک فایل چندرسانه ای را درک کنند.
زیرنویس‌ها یک نسخه متنی از تمام اطلاعات مهم ارائه شده از طریق صدا را ارائه می‌دهند. این می تواند شامل دیالوگ، صداها (طبیعی و مصنوعی)، محیط و پس زمینه، اعمال و عبارات افراد و حیوانات، متن یا گرافیک باشد. [15] راهنماهای خارج از ویکی‌پدیا برای چگونگی ایجاد زیرنویس‌ها باید مورد مشورت قرار گیرند. [16]
زیرنویس سخنرانی، اشعار، گفتگو و غیره [17] را می توان به راحتی به فایل های صوتی اضافه کرد. روش مشابه ویدیو است: :commons:Commons:Video § زیرنویس و زیرنویس بسته.
به طور کلی، استایل‌ها برای جداول و سایر عناصر سطح بلوک باید با استفاده از کلاس‌های CSS تنظیم شوند، نه با ویژگی‌های سبک درون خطی. CSS سرتاسر سایت در MediaWiki:Common.css برای اطمینان از دسترسی (مثلاً تضاد رنگ کافی) و سازگاری با طیف وسیعی از مرورگرها با دقت بیشتری آزمایش شده است. علاوه بر این، به کاربران با نیازهای بسیار خاص اجازه می‌دهد تا طرح‌های رنگی را در شیوه نامه خود تغییر دهند ( Special:MyPage/skin.css ، یا شیوه نامه مرورگر خود). برای مثال، یک برگه سبک در ویکی‌پدیا: برگه‌های سبک برای کاربران کم‌بینا، پس‌زمینه‌های کنتراست بالاتری را برای جعبه‌های ناوبری فراهم می‌کند . مشکل این است که وقتی کلاس‌های پیش‌فرض در سراسر سایت نادیده گرفته می‌شوند، انتخاب موضوع برای یک فرد بسیار دشوارتر می‌شود.
همچنین با اطمینان از ظاهر ثابت بین مقالات و مطابقت با راهنمای سبک، درجه بیشتری از حرفه ای بودن را ایجاد می کند.
در مورد دسترسی، انحراف از قراردادهای استاندارد تا زمانی که در دسترس باشد ممکن است قابل تحمل باشد. اعضای پروژه دسترس‌پذیری اطمینان حاصل کرده‌اند که سبک پیش‌فرض قابل دسترسی است. اگر برخی از الگوها یا طرح‌های رنگی خاص از استاندارد منحرف شود، نویسندگان آن باید مطمئن شوند که الزامات دسترسی مانند ارائه کنتراست رنگ کافی را برآورده می‌کند . به عنوان مثال، جعبه اطلاعات و جعبه ناوبری مربوط به یک تیم ورزشی ممکن است از طرح رنگ زرد و قرمز استفاده کنند تا با رنگ‌های رنگ تیمی هماهنگ شوند. در این مورد، پیوندهای قرمز تیره روی زرد روشن، کنتراست رنگی کافی را فراهم می‌کنند و بنابراین قابل دسترسی خواهند بود، در حالی که سفید روی زرد یا سیاه روی قرمز این امکان را ندارند.
به طور کلی، مقالات باید از نشانه گذاری ویکی در اولویت به مجموعه محدود عناصر مجاز HTML استفاده کنند. به ویژه، از عناصر سبک HTML <i>و <b>برای قالب بندی متن استفاده نکنید . ترجیحاً به ترتیب از نشانه گذاری ویکی ''یا '''برای ایتالیک و پررنگ کردن صرفاً چاپی استفاده شود و برای تفاوت های معنادارتر از الگوها یا عناصر نشانه گذاری معنایی استفاده شود. همچنین باید از عنصر <font>در متن مقاله اجتناب شود. از , , و دیگر الگوهای نشانه گذاری معنایی ما در صورت نیاز استفاده کنید تا بر تفاوت های منطقی و نه فقط روی تفاوت های بصری تأکید کنید. از الگوهای {{ subst:small }}، {{ subst:small }} و {{ subst:Large }} برای تغییر اندازه قلم استفاده کنید، به جای تنظیم صریح آن با ویژگی های سبک CSS مانند یا عناصر سبک منسوخ شده مانند . البته استثنائات طبیعی وجود دارد. به عنوان مثال، ممکن است استفاده از عنصر برای نشان دادن چیزی مانند پیوند مثالی مفید باشد که واقعاً قابل کلیک نیست، اما در غیر این صورت معمولاً زیر خط کشیدن در متن مقاله استفاده نمی شود .{{em}}{{code}}{{var}}font-size<big /><u>...</u>
عناصر جمع‌شده خودکار (از پیش جمع‌شده) نباید برای پنهان کردن محتوا در بدنه اصلی مقاله استفاده شوند.
مقالات ویکی‌پدیا باید برای خوانندگانی که از مرورگرها و دستگاه‌هایی استفاده می‌کنند که پشتیبانی محدودی از جاوا اسکریپت یا برگه‌های سبک آبشاری دارند ، که از آن به عنوان « پیشرفت پیشرونده » در توسعه وب یاد می‌شود، استفاده می‌کنند، در دسترس باشند. به یاد داشته باشید که محتوای ویکی‌پدیا را می‌توان آزادانه به روش‌هایی که نمی‌توانیم پیش‌بینی کنیم و همچنین مستقیماً از طریق مرورگرهای قدیمی‌تر به آن دسترسی پیدا می‌کند، استفاده کرد. در عین حال، تشخیص داده شده است که ارائه کیفیت ظاهری یکسان به چنین کاربرانی بدون اجتناب بی مورد از ویژگی هایی که به کاربران با مرورگرهای توانمندتر سود می رساند، غیرممکن است. به این ترتیب، ویژگی هایی که باعث مخفی شدن یا خراب شدن محتوا در زمانی که CSS یا جاوا اسکریپت در دسترس نیست، نباید استفاده شوند. با این حال، توجه به کاربران بدون CSS یا جاوا اسکریپت باید عمدتاً برای اطمینان از امکان تجربه خواندن آنها گسترش یابد . به رسمیت شناخته شده است که به ناچار پایین تر خواهد بود .
برای رعایت این ملاحظات، هرگونه تغییر احتمالی مخرب را با غیرفعال کردن جاوا اسکریپت یا CSS آزمایش کنید. در فایرفاکس یا کروم، این کار را می توان به راحتی با افزونه Web Developer انجام داد. جاوا اسکریپت را می توان در سایر مرورگرها در صفحه "گزینه ها" غیرفعال کرد. به ویژه در مورد جلوه های CSS درون خطی که توسط چندین مرورگر، رسانه و نسخه های XHTML پشتیبانی نمی شوند، مراقب باشید.
در سال 2016، حدود 7 درصد از بازدیدکنندگان ویکی‌پدیا منابع جاوا اسکریپت را درخواست نکردند. [18] [ نیاز به بروز رسانی دارد ]
{{lang}}<dl><dt>...</dt><dd>...</dd></dl>dlعنصر فرزند مورد نیاز را ندارد."