fixed alt text

Author: markingmyname

articles/mysql/flexible-server/overview.md

@@ -70,11 +70,11 @@ Azure Database for MySQL flexible server allows configuring high availability wi
 
 - **Zone Redundant High Availability (HA):** This option is preferred for complete isolation and infrastructure redundancy across multiple availability zones. It provides highest level of availability, but it requires you to configure application redundancy across zones. Zone redundant HA is preferred when you want to achieve highest level of availability against any infrastructure failure in the availability zone and where latency across the availability zone is acceptable. Zone redundant HA is available in [subset of Azure regions](overview.md#azure-regions) where the region supports multiple Availability Zones and Zone redundant Premium file shares are available.
 
-:::image type="content" source="media/concepts-high-availability/1-flexible-server-overview-zone-redundant-ha.png" alt-text="Zone redundant HA." lightbox="media/concepts-high-availability/1-flexible-server-overview-zone-redundant-ha.png":::
+:::image type="content" source="media/concepts-high-availability/1-flexible-server-overview-zone-redundant-ha.png" alt-text="Screenshot of the zone-redundant HA." lightbox="media/concepts-high-availability/1-flexible-server-overview-zone-redundant-ha.png":::
 
 - **Same-Zone High Availability (HA):** This option is preferred for infrastructure redundancy with lower network latency as both primary and standby server are in the same availability zone. It provides high availability without configuring application redundancy across zones. Same-Zone HA is preferred when you want to achieve highest level of availability within a single Availability zone with the lowest network latency. Same-Zone HA is available in [all Azure regions](overview.md#azure-regions) where you can create Azure Database for MySQL flexible server instances.
 
-:::image type="content" source="media/concepts-high-availability/flexible-server-overview-same-zone-ha.png" alt-text="Zone redundant high availability." lightbox="media/concepts-high-availability/flexible-server-overview-same-zone-ha.png":::
+:::image type="content" source="media/concepts-high-availability/flexible-server-overview-same-zone-ha.png" alt-text="Screenshot of the zone-redundant high availability." lightbox="media/concepts-high-availability/flexible-server-overview-same-zone-ha.png":::
 
 For more information, see [high availability concepts](concepts-high-availability.md).
 

articles/mysql/migrate/concepts-migrate-mydumper-myloader.md

@@ -43,8 +43,6 @@ Before you begin migrating your MySQL database, you need to:
 
 1. Install mysql client, do the following steps:
 
-4.
-
 - Update the package index on the Azure VM running Linux by running the following command:
 
 ```bash

articles/mysql/migrate/how-to-migrate-single-flexible-minimum-downtime.md

@@ -136,7 +136,7 @@ To configure Data in replication, perform the following steps:
 
     The results should appear as shown in the following image:
 
-    :::image type="content" source="media/how-to-migrate-single-flexible-minimum-downtime/metadata.png" alt-text="Continuous sync with the Azure Database Migration Service.":::
+    :::image type="content" source="media/how-to-migrate-single-flexible-minimum-downtime/metadata.png" alt-text="Screenshot of the continuous sync with the Azure Database Migration Service.":::
 
     Make sure to note the binary file name for use in later steps.
 

articles/mysql/migrate/mysql-on-premises-azure-db/08-data-migration.md

@@ -249,11 +249,11 @@ CALL Migration_PerformInventory('reg_app');
 
   - Calling this procedure on the source DB reveals the following (truncated output):
 
-:::image type="content" source="media/08-data-migration/image4.jpg" alt-text="Truncated output." lightbox="media/08-data-migration/image4.jpg":::
+:::image type="content" source="media/08-data-migration/image4.jpg" alt-text="Screenshot of truncated output." lightbox="media/08-data-migration/image4.jpg":::
 
   - The target database procedure result should resemble the image below after completing the migration. Notice there are no functions in the DB.Functions were eliminated before the migration.
 
-:::image type="content" source="media/08-data-migration/image5.jpg" alt-text="DB Functions." lightbox="media/08-data-migration/image5.jpg":::
+:::image type="content" source="media/08-data-migration/image5.jpg" alt-text="Screenshot of DB Functions." lightbox="media/08-data-migration/image5.jpg":::
 
 ## Users and permissions
 

articles/mysql/migrate/mysql-on-premises-azure-db/09-data-migration-with-mysql-workbench.md

@@ -70,7 +70,7 @@ To support the migration, set the target MySQL instance parameters to allow for
 
 - `max\_connections` - If using a tool that generates multiple threads to increase throughput, increase the connections to support that tool. Default is `151`, max is `5000`.
 
-    > [!NOTE]  
+    > [!NOTE]
     > Take care when performing scaling. Some operations can't be undone, such as storage scaling.
 
 These settings can be updated using the Azure PowerShell cmdlets below:
@@ -114,13 +114,13 @@ With the database objects and users from the source system migrated, the migrati
 
 - Also, select the **Include Create Schema** checkbox. Refer to the image below to observe the correct mysqldump configuration.
 
-    :::image type="content" source="media/09-data-migration-with-mysql-workbench/image6.jpg" alt-text="Include Create Schema." lightbox="media/09-data-migration-with-mysql-workbench/image6.jpg":::
+    :::image type="content" source="media/09-data-migration-with-mysql-workbench/image6.jpg" alt-text="Screenshot of the include create schema." lightbox="media/09-data-migration-with-mysql-workbench/image6.jpg":::
 
     **Test**
 
 - If any of these options appear unavailable, they're likely obstructed by the Output pane. Just change the editor layout.
 
-    :::image type="content" source="media/09-data-migration-with-mysql-workbench/image7.jpg" alt-text="Editor layout.":::
+    :::image type="content" source="media/09-data-migration-with-mysql-workbench/image7.jpg" alt-text="Screenshot of the editor layout.":::
 
     **Test**
 
@@ -132,7 +132,7 @@ With the database objects and users from the source system migrated, the migrati
 
 - Find any `DEFINER` statements and either change to a valid user or remove them completely.
 
-> [!NOTE]  
+> [!NOTE]
 > This can be done by passing the `--skip-definer` in the mysqldump command. This is not an option in the MySQL Workbench; therefore, the lines need to be manually removed in the export commands. Although we point out four items to remove here, there can be other items that could fail when migrating from one MySQL version to another (such as new reserved words).
 
 - Find `SET GLOBAL` statements and either change to a valid user or remove them completely.
@@ -155,7 +155,7 @@ With the database objects and users from the source system migrated, the migrati
 
     - Select **OK**.
 
-        :::image type="content" source="media/09-data-migration-with-mysql-workbench/image8.jpg" alt-text="MySQL connection dialog box." lightbox="media/09-data-migration-with-mysql-workbench/image8.jpg":::
+        :::image type="content" source="media/09-data-migration-with-mysql-workbench/image8.jpg" alt-text="Screenshot of the MySQL connection dialog box." lightbox="media/09-data-migration-with-mysql-workbench/image8.jpg":::
 
         **MySQL connection dialog box is displayed.**