Design and Evaluation of a Mobile-Friendly College Information

3.1 Research

design The study will use a within-participant comparative design, subject to faculty approval. Each participant will test both the initial interface (Version A) and the improved interface (Version B). To reduce order and learning effects, participants should be assigned to different orders (A then B or B then A) as evenly as practical. The same task definitions and measurement rules will be used for both versions. If time or resources do not permit this design, the final paper must describe the actual alternative used rather than imply a withinparticipant experiment. RESEARCH FLOW Define portal requirements Design and develop responsive prototype Review accessibility and improve interface Recruit volunteers (future; with approval) Run usability tasks and collect measures Analyse data and report actual findings

Figure 2. Proposed research methodology flowchart; all implementation and testing steps are future work. 3.2 System requirements The prototype will include the following pages or modules: •Home page with clear links to the main sections and a small announcements area. •Courses and departments page with readable headings and structured information. •Examination notices page with dated, clearly labelled notices. •Contact and enquiry page with explicit labels, required-field indicators, and understandable feedback. •Shared navigation that remains usable at narrow and wide viewport sizes. The prototype should use fictional sample notices and non-sensitive demonstration content unless the institution has explicitly authorised use of its real content. It should not collect unnecessary personal information. If an enquiry form is included, a local demonstration or non-submitting mock form is sufficient for usability testing. 3.3 Technology stack The recommended stack is HTML5 for semantic structure, CSS3 for layout and responsive media queries, and basic JavaScript for small interactive behaviours such as a mobile navigation menu and form validation. A database and authentication are not required for the first prototype. The implementation environment may be a code editor and a modern browser; hosting may use a static hosting service if approved by the project supervisor. The final manuscript must state the actual browser, device, operating system, viewport sizes, and tool versions used. 3.4 Accessibility improvement checklist •Use semantic landmarks, a logical heading hierarchy, and meaningful page titles. •Provide descriptive text for meaningful images and empty alternative text for decorative images. •Check text/background contrast and avoid communicating status through colour alone. •Ensure keyboard access, a visible focus indicator, and a logical focus order. •Provide persistent labels, instructions, and understandable validation feedback for forms. •Use descriptive link and button names, and make interactive targets comfortable to activate. •Verify that content reflows without unnecessary horizontal scrolling at the tested viewport widths. •Manually inspect automated-tool findings and record false positives or items needing review. 3.5 System architecture

Figure 1 shows the proposed three-layer system architecture. A user accesses the portal through a mobile or desktop browser; the presentation layer displays responsive pages, while the client-side interaction layer supports the mobile menu and form validation. Portal information is represented as demonstration content; a database is not required for the initial prototype. CCESS RESPONSIVE PORTAL CLIENT-SIDE FUNCTIONS visitor Mobile or desktop browser HTML5 + CSS3 Mobile menu + form validation

Figure 1. Proposed system architecture (conceptual; not yet implemented).

The portal has not yet been developed and the evaluation has not been conducted. Therefore, there are no actual participants, measurements, or experimental results to report. The following outcomes are expected only and must be verified through future implementation and testing. After development, the proposed evaluation will compare task success, completion time, user errors, accessibility findings, and System Usability Scale (SUS) scores for the initial and improved interfaces. Any claim of improvement will be made only if supported by collected data. •Expected benefits include easier access to college information on mobile devices, clearer navigation, and improved awareness of accessibility barriers. These are anticipated benefits, not measured findings. •The proposed evaluation combines task-based usability testing, accessibility inspection, and subjective usability ratings. •The planned procedure can be repeated after future design changes. •If validated, the findings may offer practical guidance to colleges with limited development resources.

Data availability: No portal implementation, participant testing, or participant data are available at this proposal stage. 1. [6] J. Rubin and D. Chisnell, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, 2nd ed. Indianapolis, IN: Wiley, 2008. 2. [7] J. Sauro and J. R. Lewis, Quantifying the User Experience: Practical Statistics for User Research, 2nd ed. Cambridge, MA: Morgan Kaufmann, 2016. 3. [8] J. Lazar, J. H. Feng, and H. Hochheiser, Research Methods in Human-Computer Interaction, 2nd ed. Cambridge, MA: Morgan Kaufmann, 2017. 4. [9] D. A. Norman, The Design of Everyday Things: Revised and Expanded Edition. New York: Basic Books, 2013. 5. [10] S. Krug, Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability, 3rd ed. Berkeley, CA: New Riders, 2014. 6. [11] ISO, ISO 9241-11:2018, Ergonomics of Human-System Interaction—Part 11: Usability: Definitions and Concepts. Geneva: International Organization for Standardization, 2018. https://www.iso.org/standard/63500.html 7. [12] W3C Web Accessibility Initiative, “Evaluating Web Accessibility Overview.” https://www.w3.org/WAI/test-evaluate/ 8. [13] W3C Web Accessibility Initiative, “Selecting Web Accessibility Evaluation Tools.” https://www.w3.org/WAI/testevaluate/tools/selecting/ 9. [14] W3C Web Accessibility Initiative, “Easy Checks—A First Review of Web Accessibility.” https://www.w3.org/WAI/testevaluate/preliminary/ 10. [15] W3C Web Accessibility Initiative, “Web Accessibility Evaluation

Tools

List.” https://www.w3.org/WAI/test-evaluate/tools/list/ 11. [16] W3C Web Accessibility Initiative, “Guidance on Applying WCAG

2.2

to

Mobile

Applications.” https://www.w3.org/TR/wcag2mobile-22/