মোবাইল অ্যাপে অ্যাক্সেসিবিলিটি
এই পাঠে যা শিখবেন
- মোবাইল অ্যাক্সেসিবিলিটির চারটি মূল স্তম্ভ ও প্রতিটির উদ্দেশ্য
- স্ক্রিন রিডার কীভাবে কাজ করে এবং কেন লেবেল অপরিহার্য
- WCAG কালার কনট্রাস্ট নিয়ম ও এর পেছনের গণিত (relative luminance)
- RGB রঙের জোড়া থেকে কনট্রাস্ট রেশিও genuinely গণনা করার একটি Python ফাংশন
১ · মোবাইল অ্যাক্সেসিবিলিটির চারটি স্তম্ভ
অ্যাক্সেসিবিলিটি (accessibility) মানে এমনভাবে অ্যাপ ডিজাইন করা যাতে দৃষ্টি, শ্রবণ, বা মোটর সীমাবদ্ধতা থাকা ব্যবহারকারীরাও এটি ব্যবহার করতে পারেন। মোবাইলে এর চারটি সুপরিচিত, ব্যবহারিক স্তম্ভ আছে —
Android-এ TalkBack, iOS-এ VoiceOver — স্ক্রিনে থাকা টেক্সট/লেবেল জোরে পড়ে শোনায়, যাতে দৃষ্টি-প্রতিবন্ধী ব্যবহারকারী স্পর্শ করে UI নেভিগেট করতে পারেন।
L06-এ কভার করা ~৪৪-৪৮dp/pt নিয়ম — মোটর-সীমাবদ্ধতাযুক্ত ব্যবহারকারীদের জন্যও এটি সমান গুরুত্বপূর্ণ, শুধু "সুবিধাজনক" নয়।
ফোরগ্রাউন্ড টেক্সট ও ব্যাকগ্রাউন্ডের মধ্যে যথেষ্ট রঙের পার্থক্য — কম দৃষ্টিশক্তি বা রঙ-অন্ধত্বযুক্ত ব্যবহারকারীদের জন্য টেক্সট পড়া সম্ভব রাখে।
ব্যবহারকারী OS-লেভেল সেটিংসে ফন্ট সাইজ বড় করলে অ্যাপের টেক্সটও সেই অনুযায়ী স্কেল হওয়া উচিত — হার্ডকোড করা ফিক্সড ফন্ট সাইজ এই সুবিধা ভেঙে দেয়।
২ · কালার কনট্রাস্ট — WCAG-এর গণিত
"যথেষ্ট কনট্রাস্ট" একটি অস্পষ্ট বিষয়গত মতামত নয় — WCAG এটিকে একটি সুনির্দিষ্ট সূত্রে পরিণত করেছে। প্রতিটি রঙের একটি রিলেটিভ লুমিন্যান্স (আপেক্ষিক উজ্জ্বলতা, ০ থেকে ১) গণনা করা হয়, তারপর দুটি রঙের লুমিন্যান্স থেকে একটি কনট্রাস্ট রেশিও বের করা হয়। সাধারণ টেক্সটের জন্য WCAG AA স্ট্যান্ডার্ড ন্যূনতম ৪.৫:১ কনট্রাস্ট রেশিও সুপারিশ করে।
# WCAG-স্টাইল কনট্রাস্ট-রেশিও ক্যালকুলেটর -- relative luminance ফর্মুলা দিয়ে genuinely গণনা করা
def relative_luminance(rgb):
def channel(c):
c = c / 255
if c <= 0.03928:
return c / 12.92
else:
return ((c + 0.055) / 1.055) ** 2.4
r, g, b = rgb
R, G, B = channel(r), channel(g), channel(b)
return 0.2126 * R + 0.7152 * G + 0.0722 * B
def contrast_ratio(fg, bg):
l1 = relative_luminance(fg)
l2 = relative_luminance(bg)
lighter, darker = max(l1, l2), min(l1, l2)
return (lighter + 0.05) / (darker + 0.05)
MIN_CONTRAST_AA = 4.5
pairs = [
("কালো টেক্সট / সাদা ব্যাকগ্রাউন্ড", (0, 0, 0), (255, 255, 255)),
("হালকা ধূসর টেক্সট / সাদা ব্যাকগ্রাউন্ড", (170, 170, 170), (255, 255, 255)),
("গাঢ় নীল টেক্সট / হালকা নীল ব্যাকগ্রাউন্ড", (0, 51, 102), (204, 229, 255)),
]
for label, fg, bg in pairs:
ratio = contrast_ratio(fg, bg)
passed = ratio >= MIN_CONTRAST_AA
status = "পাস" if passed else "ফেইল"
print(f"{label:40s} | কনট্রাস্ট={ratio:.2f}:1 | {status}")"হালকা ধূসর টেক্সট / সাদা ব্যাকগ্রাউন্ড" জোড়াটি ফেইল করে — যদিও ধূসর টেক্সট
(170,170,170) সাদা ব্যাকগ্রাউন্ডে "দেখা যায়", কিন্তু কনট্রাস্ট রেশিও ৪.৫:১ ছাড়িয়ে যায় না, তাই কম
দৃষ্টিশক্তির ব্যবহারকারীর জন্য পড়া কঠিন হতে পারে। শুধু "চোখে দেখা যাচ্ছে" যথেষ্ট নয় — WCAG-এর সুনির্দিষ্ট
থ্রেশহোল্ড পূরণ করা দরকার।
অ্যাক্সেসিবিলিটি কোনো "অতিরিক্ত ফিচার" নয় — এটি একই ডিজাইন সিদ্ধান্তগুলোর (টাচ টার্গেট সাইজ, রঙ পছন্দ, টেক্সট সাইজ) মধ্যে ইতিমধ্যে বিদ্যমান, শুধু পরিমাপযোগ্য থ্রেশহোল্ড দিয়ে যাচাই করা। L09-এ ডার্ক মোড ও থিমিং শেখার সময় এই একই কনট্রাস্ট বিবেচনা প্রতিটি থিমের জন্য আলাদাভাবে যাচাই করা প্রয়োজন হবে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি বাটনে শুধু একটি আইকন আছে, কোনো টেক্সট নেই — স্ক্রিন রিডার ব্যবহারকারীর জন্য এটি কী সমস্যা তৈরি করতে পারে?
যদি বাটনটিতে একটি আলাদা, অ-ভিজ্যুয়াল "অ্যাক্সেসিবিলিটি লেবেল" (যেমন "মুছে ফেলুন" বা "শেয়ার করুন") না থাকে, স্ক্রিন রিডার হয়তো শুধু "বাটন" বলবে বা আইকনের ফাইলনামের মতো অর্থহীন কিছু পড়বে — ব্যবহারকারী বুঝতে পারবেন না বাটনটি কী করে। তাই আইকন-অনলি বাটনেও একটি অর্থবহ, লুকানো টেক্সট লেবেল যুক্ত করা জরুরি।
প্র ০২ টেক্সটের ফন্ট সাইজ হার্ডকোড করে (যেমন সবসময় ঠিক ১৪px) রাখলে ডায়নামিক টাইপের সাথে কী দ্বন্দ্ব তৈরি হয়?
ব্যবহারকারী যদি তার ফোনের OS সেটিংসে ফন্ট সাইজ বড় করে থাকেন (দৃষ্টিশক্তি সহায়তার জন্য), কিন্তু অ্যাপ একটি নির্দিষ্ট পিক্সেল সাইজে "লক" করা থাকে, তাহলে সেই টেক্সট বাকি সিস্টেম UI-এর তুলনায় অস্বাভাবিক ছোট দেখাবে এবং OS-এর accessibility সেটিং উপেক্ষা করবে — ব্যবহারকারীর জন্য অ্যাপটি কার্যত অ্যাক্সেসযোগ্য থাকবে না, যদিও বাকি সব সঠিক থাকে।
প্র ০৩
উপরের কোড সেলে contrast_ratio() ফাংশনে lighter ও darker আলাদা করে বের করা হয় কেন — সরাসরি l1 ও l2 ব্যবহার করলে কী সমস্যা হতো?
WCAG-এর কনট্রাস্ট সূত্র নির্দিষ্টভাবে (lighter + 0.05) / (darker + 0.05) — অর্থাৎ সবসময়
উজ্জ্বল রঙকে লবে (numerator) ও গাঢ় রঙকে হরে (denominator) বসাতে হয়, ফোরগ্রাউন্ড/ব্যাকগ্রাউন্ড যে
ক্রমেই দেওয়া হোক না কেন। যদি সরাসরি (l1 + 0.05) / (l2 + 0.05) ব্যবহার করা হতো এবং
fg ব্যাকগ্রাউন্ডের চেয়ে গাঢ় হতো, তাহলে ফলাফল ১-এর কম একটি ভগ্নাংশ হতো — যা কনট্রাস্ট
রেশিও হিসেবে ভুল ও থ্রেশহোল্ড-তুলনায় সবসময় ফেইল দেখাত, প্রকৃত কনট্রাস্ট যাই হোক না কেন।
অনুশীলন
-
চিন্তা করুন: ফোনের অ্যাক্সেসিবিলিটি সেটিংসে গিয়ে (বা কল্পনা করে) স্ক্রিন রিডার সংক্ষিপ্ত
সময়ের জন্য চালু করলে আপনার প্রিয় কোনো অ্যাপ ব্যবহার করা কতটা সহজ/কঠিন হতো বলে মনে হয়?
অনেক অ্যাপে আইকন-অনলি বাটন, অস্পষ্ট গ্রুপিং, বা লেবেল-বিহীন ইনপুট ফিল্ড থাকে যা স্ক্রিন রিডারে বিভ্রান্তিকর মনে হয় — এই অনুশীলনটি দেখায় কেন বড় প্রযুক্তি কোম্পানিগুলো ডিজাইন রিভিউয়ের অংশ হিসেবে নিয়মিত স্ক্রিন-রিডার টেস্টিং করে।
-
পরীক্ষা করুন: উপরের কোড সেলে
pairsলিস্টে একটি নতুন জোড়া যোগ করুন —("সাদা টেক্সট / হালকা হলুদ ব্যাকগ্রাউন্ড", (255, 255, 255), (255, 255, 0))— এবং চালিয়ে দেখুন এটি ৪.৫:১ থ্রেশহোল্ড পাস করে কি না।সাদা (255,255,255)-এর লুমিন্যান্স সর্বোচ্চ (১.০) আর হলুদ (255,255,0)-এর লুমিন্যান্স তুলনামূলক বেশি (হলুদ একটি উজ্জ্বল রঙ), তাই দুই রঙের মধ্যে কনট্রাস্ট কম থাকবে এবং এটি ৪.৫:১ থ্রেশহোল্ডে ফেইল করবে — দেখায় কেন হালকা রঙের উপর সাদা টেক্সট প্রায়ই একটি সাধারণ কনট্রাস্ট ভুল।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Full-Stack Web Frameworks কোর্স সহোদর কোর্স WCAG কনট্রাস্ট নিয়ম মূলত ওয়েব অ্যাক্সেসিবিলিটি স্ট্যান্ডার্ড হিসেবে তৈরি — মোবাইল প্ল্যাটফর্মগুলো এই একই সুপরিচিত থ্রেশহোল্ড গ্রহণ করেছে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।