WCAG 1.4.4: تغيير حجم النص

ماذا تعني هذه القاعدة

تنص إرشادات WCAG 1.4.4 لتغيير حجم النص (المستوى AA) على أن النص يجب أن يكون قابلاً لتغيير الحجم حتى 200 بالمئة دون استخدام تقنيات مساعدة ودون فقدان المحتوى أو الوظائف. بعبارة مبسطة، عندما يقوم المستخدم بتكبير المتصفح إلى 200% أو تكبير حجم الخط الأساسي من خلال إعدادات المتصفح أو نظام التشغيل، يجب أن يبقى كل نص في الصفحة قابلاً للقراءة وأن تبقى جميع الوظائف سليمة.

ينطبق هذا المعيار بشكل واسع على كل النصوص المعروضة في صفحة الويب، بما في ذلك نصوص المتن، العناوين، التسميات، نص الأزرار، النصوص النائبة داخل حقول النماذج، روابط التنقل، محتوى الجداول، والتسميات التوضيحية. ولا ينطبق على النص الذي يشكل جزءاً من شعار أو اسم علامة تجارية، ولا على النصوص الزخرفية التي لا تنقل أي معلومات وتُعرض فقط كمحتوى صوري (مثل صورة ممسوحة ضوئياً لملاحظة مكتوبة بخط اليد حيث لا يُعد النص نفسه هو المحتوى المتاح).

يتطلب النجاح أنه عند تكبير العرض إلى 200% — سواء عبر ميزة التكبير المدمجة في المتصفح (Ctrl/Cmd + مفتاح الزائد أو قائمة View > Zoom) أو عبر إعداد الحد الأدنى لحجم الخط في المتصفح — تتحقق الشروط التالية: لا يتم اقتطاع النص أو إخفاؤه داخل حاويته، لا يتداخل النص مع نص آخر أو عناصر تفاعلية، لا يظهر شريط تمرير أفقي عند عرض الصفحة بكامل عرض نافذة العرض (باستثناء المحتوى الذي يتطلب فعلياً تمريراً ثنائياً مثل الخرائط أو جداول البيانات)، وتبقى جميع عناصر التحكم التفاعلية قابلة للاستخدام.

يتم تسجيل فشل عندما تؤدي قيم البكسل الثابتة إلى تثبيت النص على حجم لا يمكن أن يكبر، أو عندما تستخدم الحاويات ارتفاعات ثابتة تقطع النص المتجاوز، أو عندما تستخدم وسوم meta الخاصة بالمنظور (viewport) القيم user-scalable=no أو maximum-scale=1.0 لمنع التكبير بالإيماءات على الأجهزة المحمولة، أو عندما يعترض JavaScript إيماءات التكبير لمنع التحجيم. هذا المعيار محايد صراحةً من ناحية التقنية: سواء تم التنفيذ باستخدام CSS أو نص SVG أو نص مرسوم على canvas، فالنتيجة بالنسبة للمستخدم هي ما يهم. لاحظ أن نص SVG والنص المرسوم على canvas يصعب تغيير حجمهما بطبيعتهما وغالباً ما يتطلبان جهداً هندسياً إضافياً.

لماذا يهم

وفقاً لمنظمة الصحة العالمية، يعاني حوالي 2.2 مليار شخص حول العالم من شكل من أشكال ضعف البصر. ومن بين هؤلاء، يعاني جزء كبير جداً من ضعف البصر المتوسط — وهي حالة لا يمكن فيها تصحيح البصر بالكامل باستخدام النظارات أو العدسات اللاصقة، لكن الشخص لا يكون أعمى تماماً. يستخدم الأشخاص ضعيفو البصر عادة تكبير المتصفح إلى 150% أو 200% أو أكثر، أو يضبطون نظام التشغيل لعرض النص بحجم أساسي أكبر. عندما تقوم المواقع بحظر هذا السلوك أو تعطيله، يتم استبعاد هؤلاء المستخدمين تماماً من المحتوى.

إضافة إلى ضعف البصر المشخّص، تؤثر العوامل الظرفية عملياً على كل مستخدم للإنترنت في مرحلة ما: الشاشات الصغيرة، ضوء الشمس الساطع، التعب، تراجع حدة البصر مع التقدم في العمر، أو القراءة بلغة غير مألوفة يمكن أن تجعل النص الأصغر أصعب في الفهم. يعتمد كبار السن على وجه الخصوص — وهم فئة سكانية تنمو بسرعة عالمياً وفي تركيا — على التكبير كحل أولي لإتاحة الوصول قبل اللجوء إلى تقنيات مساعدة متخصصة.

فكر في سيناريو ملموس: مريض في الستينيات من عمره يحاول قراءة تأكيد موعده عبر الإنترنت من بوابة مستشفى على هاتفه الذكي. تحدد ورقة الأنماط الخاصة بالهاتف المحمول في المستشفى حجم خط المتن بـ 12px باستخدام قيمة بكسل ثابتة، ويتضمن وسم المنظور (viewport) القيمة maximum-scale=1.0. يحاول المريض التكبير بإيماءة القرص لكن الواجهة تُقفل. لا يستطيع قراءة التاريخ أو اسم القسم بوضوح كافٍ ليكون واثقاً. يتصل بمكتب المساعدة في المستشفى، مما يستهلك وقت الموظفين ويخلق قلقاً للمريض — وهي نتيجة كان يمكن منعها تماماً لو تم الالتزام بهذا المعيار.

من منظور تجاري بحت، يرتبط إتاحة تغيير حجم النص بتحسينات أوسع في سهولة الاستخدام تفيد جميع المستخدمين. كما تكافئ محركات البحث المواقع التي تعرض نصاً قابلاً للقراءة بأحجام عادية ومكبّرة، لأن Googlebot يقيم إشارات قابلية القراءة كجزء من مؤشرات Core Web Vitals وعوامل ترتيب تجربة الصفحة. وبالتالي فإن إصلاح مشكلات تغيير الحجم يحسن تحسين محركات البحث (SEO)، ويقلل عبء الدعم، ويوسع الجمهور المحتمل في الوقت نفسه.

قواعد Axe-core ذات الصلة

تُعد WCAG 1.4.4 في الأساس معياراً للاختبار اليدوي. يمكن للأدوات الآلية الإشارة إلى مجموعة ضيقة من الحالات المعروفة بأنها تمنع تغيير حجم النص، لكنها لا تستطيع محاكاة وتقييم جميع نتائج التخطيط عند تكبير 200% بشكل موثوق. الحالات التالية هي ما تحاول الأدوات الآلية اكتشافه، وما يتطلب متابعة يدوية:

• وسم meta للمنظور الذي يمنع التكبير (يتطلب فحصاً يدوياً): تتضمن Axe-core قاعدة meta-viewport التي تشير إلى أي وسم <meta name='viewport'> يحدد user-scalable=no أو maximum-scale بقيمة 1.0 أو أقل. هذه هي الحالة الوحيدة التي يكون فيها الاكتشاف الآلي الكامل ممكناً، لأن الانتهاك تصريحي ولا يعتمد على نتيجة التخطيط. ومع ذلك، حتى هذه القاعدة لا يمكنها تحديد ما إذا كان الموقع يستخدم JavaScript لمنع التكبير برمجياً، لذا يلزم دائماً التحقق اليدوي.
• أحجام خطوط ثابتة بوحدة البكسل (يتطلب فحصاً يدوياً): يمكن للأدوات الآلية الإبلاغ عندما يتم تعيين قيم CSS الخاصة بـ font-size بوحدات بكسل مطلقة (px) بدلاً من الوحدات النسبية (em أو rem أو % أو الوحدات النسبية لنافذة العرض). ومع ذلك، تتجاوز المتصفحات الحديثة أحجام الخطوط بالبكسل المطلقة عندما يغير المستخدم حجم الخط الافتراضي في المتصفح، لذا فإن قيمة البكسل وحدها لا تشكل فشلاً مضموناً — فهذا يعتمد على سلوك المتصفح وما إذا كان الموقع يحترم توريث font-size. يلزم الفحص اليدوي للأنماط المحسوبة والتحقق البصري لتأكيد الفشل الفعلي.
• تجاوز المحتوى وحدوث الاقتطاع عند تكبير 200% (يدوي فقط): لا يمكن لأي أداة آلية أن تعرض صفحة عند 200% وتقيّم بشكل موثوق ما إذا كان كل النص يبقى مرئياً وكل العناصر التفاعلية تبقى قابلة للاستخدام. يتطلب ذلك من مختبر بشري ضبط مستوى تكبير المتصفح، والتمرير عبر الصفحة، والتحقق من كل منطقة محتوى. لا تملك الأدوات الآلية إمكانية الوصول إلى حالة العرض بعد التكبير.
• النص داخل الصور وcanvas (يدوي فقط): النص المدمج داخل الصور النقطية (<img> التي تحتوي على لقطات شاشة لنص) أو المرسوم على عنصر <canvas> لا يمكن تغيير حجمه بواسطة المتصفح على الإطلاق. يمكن للأدوات الآلية الإشارة إلى وجود عناصر canvas للمراجعة اليدوية، لكنها لا تستطيع تحديد ما إذا كانت هذه العناصر تحتوي على نص ذي معنى يحتاج المستخدم إلى قراءته.

كيفية الاختبار

1. قم بتشغيل فحص آلي أولاً. افتح الصفحة في Chrome أو Firefox وشغّل axe DevTools (امتداد المتصفح) أو Lighthouse (أدوات مطوري Chrome، تبويب Lighthouse). ابحث تحديداً عن انتهاك قاعدة meta-viewport. إذا تم الإشارة إليه، فدوّنه كفشل حرج. تحقق أيضاً من تدقيق CSS لأي تعريفات font-size بوحدة px تظهر في تحذيرات أفضل الممارسات في axe.
2. تحقق من وسم meta الخاص بالمنظور في الشيفرة المصدرية. افتح أدوات المطور (F12)، انتقل إلى تبويب Elements، وابحث عن meta name='viewport'. اقرأ خاصية content بعناية. إذا احتوت على user-scalable=no أو user-scalable=0 أو maximum-scale=1 (أو أي قيمة أقل من 2)، فهذا فشل مباشر لمعيار 1.4.4.
3. اضبط تكبير المتصفح إلى 200%. في Chrome أو Firefox، اضغط Ctrl + Plus (في Windows/Linux) أو Cmd + Plus (في macOS) بشكل متكرر حتى يشير مؤشر التكبير في المتصفح إلى 200%. بدلاً من ذلك، انتقل إلى View > Zoom In. في Safari على macOS، استخدم View > Zoom In. لا تستخدم تحجيم العرض على مستوى نظام التشغيل لهذا الاختبار — استخدم تكبير المتصفح تحديداً.
4. قم بالتمرير عبر كل قسم من الصفحة عند تكبير 200%. قم بالتمرير بشكل منهجي من أعلى إلى أسفل. ابحث عن: نص مقطوع أو مخفي داخل حاويته، نص يتجاوز صندوقه ويتداخل مع محتوى مجاور، تسميات نماذج تختفي خلف حقول الإدخال الخاصة بها، أزرار يتم اقتطاع نصها، قوائم منسدلة تمتد خارج الشاشة ولا يمكن تمريرها إلى مجال الرؤية، وحوارات منبثقة تتجاوز نافذة العرض ولا يمكن تمريرها.
5. اختبر كل الوظائف التفاعلية عند تكبير 200%. فعّل كل قوائم التنقل، وافتح كل الحوارات المنبثقة، وأرسل النماذج، وفعّل التلميحات المنبثقة (tooltips) والنوافذ المنبثقة (popovers)، وتفاعل مع أي شرائح عرض (carousels) أو عناصر accordion. تحقق من أن كل هذه العناصر تبقى قابلة للاستخدام بالكامل — وليس مجرد ظاهرة بصرياً.
6. اختبر باستخدام NVDA + Firefox (Windows). فعّل NVDA وافتح Firefox عند تكبير 200%. تنقل باستخدام مفتاح Tab ومفاتيح الأسهم. تأكد من أن العناصر القابلة للتركيز تستقبل التركيز، وأن مؤشرات التركيز مرئية (يتداخل هذا مع معيار WCAG 2.4.7 لكنه مفيد للتحقق)، وأن ترتيب القراءة يطابق الترتيب البصري عند الحجم المكبّر.
7. اختبر باستخدام VoiceOver + Safari (macOS/iOS). فعّل VoiceOver. على iOS، انتقل إلى Settings > Accessibility > Display & Text Size وفعّل Larger Text. تنقل في نفس الصفحة وتحقق من سلامة المحتوى. استخدم أيضاً إيماءة القرص للتكبير للتأكد من أنها غير محجوبة.
8. اختبر إعداد الحد الأدنى لحجم الخط في المتصفح. في Firefox، انتقل إلى Settings > General > Fonts and Colors واضبط الحد الأدنى لحجم الخط على 24px. أعد تحميل الصفحة وتحقق من أن كل النص يفي بهذا الحد الأدنى وأن التخطيط لا ينكسر. هذا يختبر مساراً مختلفاً لنفس المعيار.
9. اختبر باستخدام JAWS + Chrome (Windows). افتح الصفحة في Chrome عند تكبير 200% مع تفعيل JAWS. استخدم أوامر القراءة في JAWS (Insert + سهم لأسفل للقراءة من المؤشر) للتأكد من أن كل محتوى النص يُعلن عنه ولا يتم تخطي أي محتوى بسبب إخفائه بواسطة الاقتطاع (overflow clipping).

كيفية الإصلاح

وسم meta للمنظور الذي يمنع التكبير — غير صحيح

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

وسم meta للمنظور الذي يمنع التكبير — صحيح

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

أحجام الخط بالبكسل الثابت — غير صحيح

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

أحجام الخط بالبكسل الثابت — صحيح

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

حاويات ذات ارتفاع ثابت تقطع النص — غير صحيح

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

حاويات ذات ارتفاع ثابت تقطع النص — صحيح

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

نص مدمج داخل الصور — غير صحيح

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

نص مدمج داخل الصور — صحيح

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

الأخطاء الشائعة

• إضافة user-scalable=no إلى وسم meta الخاص بالمنظور لمنع "انكسار التخطيط" على الأجهزة المحمولة — هذا انتهاك مباشر وقابل للاختبار لمعيار 1.4.4 ويجب عدم استخدامه مطلقاً. أصلح التخطيط بدلاً من منع المستخدم من التكبير.
• تعيين maximum-scale=1.0 أو أي قيمة أقل من 2.0 — حتى بدون user-scalable=no، فإن تحديد حد أقصى للتكبير عند 1.0 أو 1.5 يمنع المستخدمين من الوصول إلى 200% ويفشل في تحقيق المعيار.
• استخدام مستمعي أحداث JavaScript لاستدعاء event.preventDefault() على إيماءات القرص للتكبير أو أحداث عجلة الفأرة — حظر التكبير الأصلي برمجياً يعادل وظيفياً نهج وسم meta للمنظور ويفشل في نفس المعيار.
• تعيين font-size بوحدة البكسل على عنصري <html> أو <body> ثم استخدام وحدات em لكل شيء آخر — إذا كان حجم خط الجذر ثابتاً بوحدة px، فإن كل العناصر التابعة بوحدات em/rem تصبح ثابتة فعلياً ولن تستجيب لتفضيل المستخدم لحجم خط المتصفح.
• استخدام height بدلاً من min-height في مكونات البطاقات أو الأشرطة الجانبية أو أجسام الحوارات المنبثقة — عند تكبير 200%، يتجاوز النص المكبّر الصناديق ذات الارتفاع الثابت ويتم اقتطاعه بواسطة overflow: hidden، مما يخفي محتوى حرجاً.
• وضع نص مهم حصرياً داخل عناصر <canvas> — النص المرسوم على canvas هو صورة نقطية ولا يمكن تحجيمه بواسطة آليات تغيير حجم النص أو التكبير في المتصفح. يجب أن يكون أي نص ذي معنى يحتاج المستخدم إلى قراءته متاحاً كنص HTML حقيقي أو على الأقل كنص بديل متاح.
• استخدام عناصر SVG <text> بإحداثيات مطلقة ودون تحجيم viewBox — يمكن أن يكون نص SVG قابلاً للتحجيم عندما يستخدم SVG خاصية viewBox ويتم تحديد حجمه بوحدات نسبية، لكن نص SVG الذي يحتوي على خصائص x وy وfont-size ثابتة بوحدة البكسل داخل SVG ذي width وheight ثابتين لا يتغير حجمه مع تكبير المتصفح في جميع المتصفحات.
• الافتراض بأن تكبير المتصفح يتكفل تلقائياً بتحقيق المعيار وتجاوز الاختبار اليدوي — يقوم تكبير المتصفح بتحجيم الصفحة بأكملها بما في ذلك الصور والتخطيط، لكن النص الذي كان صغيراً جداً أو مقطوعاً أو متداخلاً عند 100% يصبح مشكلة أسوأ عند 200%. يلزم دائماً التحقق اليدوي عند مستوى التكبير.
• نسيان اختبار الويدجت المضمنة من أطراف ثالثة — أدوات الدردشة، وإطارات الدفع المضمّنة، ولافتات موافقة ملفات تعريف الارتباط، وتراكبات التحليلات غالباً ما تُطوَّر من قبل أطراف ثالثة باستخدام أحجام ثابتة بوحدة px وقد تمنع التكبير. حتى لو كان الكود من طرف ثالث، ينطبق المعيار على الصفحة بأكملها كما تُقدَّم للمستخدم.
• إصلاح تخطيط سطح المكتب للتكبير مع إهمال نقطة التوقف الخاصة بالهاتف المحمول — تختبر العديد من الفرق التكبير على سطح المكتب وتعلن النجاح، لكن نوافذ العرض على الأجهزة المحمولة عند تكبير 200% تقدم مجموعة منفصلة من تحديات التخطيط، خاصة لقوائم التنقل، والرؤوس الثابتة، وأشرطة التنقل السفلية التي تعتمد على ارتفاعات ثابتة بوحدة البكسل.

العلاقة مع لوائح الوصول في تركيا

تحدد التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، متطلبات إلزامية لإتاحة الوصول على الويب والهاتف المحمول لفئات محددة من المنظمات العاملة في تركيا. يشير التعميم إلى معايير إتاحة الوصول المعترف بها دولياً — مما يربط فعلياً المتطلبات التركية بمعايير WCAG 2.1 وWCAG 2.2 المستوى AA كمرجع للامتثال.

يُعد معيار WCAG 1.4.4 لتغيير حجم النص معياراً من المستوى AA، والامتثال للمستوى AA هو الحد المطلوب للحصول على شعار الإتاحة (Erişilebilirlik Logosu) الصادر عن وزارة الأسرة والخدمات الاجتماعية (Aile ve Sosyal Hizmetler Bakanlığı). يُعد شعار الإتاحة في الوقت نفسه إشارة ثقة عامة ونقطة تحقق تنظيمية — فالمنظمات الخاضعة للتعميم التي ترغب في عرض الشعار أو إثبات الامتثال أمام المدققين يجب أن تفي بجميع معايير المستوى AA، بما في ذلك 1.4.4.

تشمل فئات الكيانات التي يغطيها التعميم الرئاسي 2025/10: المؤسسات والهيئات العامة على جميع مستويات الحكومة؛ منصات التجارة الإلكترونية والأسواق الإلكترونية؛ البنوك ومقدمي الخدمات المالية الخاضعين لتنظيم هيئة التنظيم والرقابة المصرفية (BDDK)؛ المستشفيات والمراكز الصحية وغيرها من مؤسسات الرعاية الصحية التي تقدم خدمات رقمية موجهة للمرضى؛ مشغلي الاتصالات الذين لديهم 200,000 مشترك أو أكثر؛ وكالات السفر والمنصات الإلكترونية للسفر؛ شركات النقل الخاصة التي تقدم خدمات حجز أو تذاكر رقمية؛ والمدارس والمؤسسات التعليمية الخاصة المرخصة من قبل وزارة التربية الوطنية (Millî Eğitim Bakanlığı, MoNE).

بالنسبة لكل من هذه الفئات من الكيانات، فإن الأثر العملي لمعيار 1.4.4 كبير. فبوابة الخدمات المصرفية عبر الإنترنت لبنك ما والتي تمنع التكبير بالإيماءات على الهاتف المحمول ليست مجرد فشل في سهولة الاستخدام — بل هي عدم امتثال تنظيمي يمكن أن يؤدي إلى ملاحظات في التدقيق أو الاستبعاد من برنامج شعار الإتاحة. نظام حجز مواعيد المستشفى الذي يستخدم أحجام خطوط ثابتة بوحدة البكسل داخل حاويات تقطع المحتوى يفشل في خدمة المرضى ضعيفي البصر ويفشل في الوقت نفسه في الوفاء بالتزاماته بموجب التعميم. منصة تسجيل مدرسة خاصة التي تدمج النص داخل الصور بدلاً من استخدام نص HTML قابل للتحجيم هي أيضاً غير ممتثلة.

يجب على المنظمات أن تتعامل مع معيار WCAG 1.4.4 ليس كخانة تقنية ضيقة يجب وضع علامة عليها، بل كتوقع أساسي للاحترام تجاه المستخدمين ذوي الإعاقات البصرية — وهو توقع تتلاقى حوله القوانين التركية وأفضل الممارسات الدولية وأبسط مبادئ سهولة الاستخدام. يدعم حزمة Accsible للتراكب (overlay SDK) الامتثال لمتطلبات تغيير حجم النص من خلال توفير عناصر تحكم قابلة للتهيئة لتحجيم الخط تسمح للمستخدمين النهائيين بزيادة حجم النص بشكل مستقل عن تكبير المتصفح، مما يوفر طبقة تيسير إضافية فوق المتطلبات الأساسية التي يجب على المواقع نفسها تنفيذها.